Medidas de tolerancia a errores del sistema

 

Última modificación del tema: 2006-08-16

Esta sección contiene consideraciones de nivel de sistema y estrategias para aumentar la tolerancia a errores de su organización de Exchange 2003. En concreto, nivel del sistema se refiere a la infraestructura de Exchange 2003 y a las recomendaciones para implementar la tolerancia a errores dentro de esa infraestructura.

En la figura siguiente se ilustra una infraestructura confiable de Exchange 2003 y se muestran las recomendaciones para mantener un nivel elevado de tolerancia a errores.

Medidas de tolerancia a errores para la infraestructura

En esta sección se describen métodos para diseñar tolerancia a errores en todos los niveles de la infraestructura de Exchange 2003. En concreto, esta sección ofrece información acerca de lo siguiente:

• Implementación de servidores de seguridad y redes perimetrales
• Cómo garantizar el acceso confiable a Active Directory y el Sistema de nombres de dominio (DNS)
• Cómo garantizar el acceso confiable a los servidores de aplicaciones para usuario de Exchange
• Configuración de servidores virtuales de protocolo de Exchange
• Implementación de una solución confiable de almacenamiento de servicios de fondo
• Implementación de una solución de clústeres de servidor
• Implementación de una estrategia de supervisión
• Implementación de una estrategia de recuperación de desastres

Implementación de servidores de seguridad y redes perimetrales

Se recomienda que su topología de Exchange 2003 incluya una red perimetral, así como una arquitectura de servidores de aplicaciones para usuario y de servicios de fondo. En la figura siguiente se ilustra esta topología, incluyendo la seguridad adicional que ofrece un servidor avanzado de proxy inverso (en este caso, Internet Security and Acceleration (ISA) Server 2000 Feature Pack 1).

La implementación de ISA Server 2000 Feature Pack 1 en una red perimetral es sólo una forma de contribuir a proteger el sistema de mensajería. Hay otros métodos que incluyen el uso de seguridad de nivel de transporte, como Seguridad del protocolo Internet (IPSec) o Secure Sockets Layer (SSL).

Para obtener información completa acerca del diseño de una topología segura de Exchange, consulte "Diseño de la infraestructura de Exchange" en Diseño de un sistema de mensajería de Exchange Server 2003.

Para obtener información acerca de cómo utilizar ISA Server 2000 con Exchange 2003, consulte Using ISA Server 2000 with Exchange Server 2003 (en inglés).

Cómo garantizar el acceso confiable a Active Directory y el Sistema de nombres de dominio

Exchange se basa en gran medida en Active Directory y en el Sistema de nombres de dominio (DNS). Para ofrecer un acceso confiable y eficiente a Active Directory y DNS, asegúrese de que los controladores de dominio, los servidores de catálogo global y los servidores de DNS están bien protegidos frente a posibles errores.

Controladores de dominio

Un controlador de dominio es un servidor que aloja la base de datos de un dominio y realiza servicios de autenticación que son necesarios para que los clientes puedan iniciar sesión y tener acceso a Exchange. (Los usuarios deben poder autenticarse mediante Exchange o Windows). Exchange 2003 utiliza los controladores de dominio para la información de configuración del sistema y de los servidores. En Windows Server 2003, la base de datos del dominio forma parte de la base de datos de Active Directory. En un bosque de dominios de Windows Server 2003, la información de Active Directory se replica entre los controladores de dominio que también contienen una copia de la configuración del bosque y los contenedores de esquema.

Un controlador de dominio puede asumir muchas funciones dentro de una infraestructura de Active Directory: un servidor de catálogo global, un maestro de operaciones o un simple controlador de dominio.

Servidores de catálogo global

Un servidor de catálogo global es un controlador de dominio que aloja el catálogo global. Un servidor de catálogo global es necesario para iniciar sesión, ya que contiene información acerca de la pertenencia a grupos universales. Esta pertenencia concede o niega a los usuarios el acceso a los recursos. Si no se puede establecer contacto con un servidor de catálogo global, no se puede determinar la pertenencia universal de un usuario y se deniega el acceso de inicio de sesión.

Debe haber al menos un servidor de catálogo global instalado en cada dominio que contenga servidores de Exchange.

Recomendaciones para controladores de dominio y servidores de catálogo global

Como los controladores de dominio contienen información esencial de Active Directory, asegúrese de que los controladores de dominio de su organización estén bien protegidos frente a posibles errores.

A continuación se ofrecen las recomendaciones para implementar y configurar controladores de dominio y servidores de catálogo global de Active Directory:

• A menos que sea un requisito para su organización, no ejecute Exchange 2003 en los controladores de dominio. Para obtener información acerca de las implicaciones de la ejecución de Exchange en un controlador de dominio, consulte “Ejecución de Exchange 2003 en un controlador de dominio” más adelante en este tema.

• Incluya al menos dos controladores de dominio en cada sitio de Active Directory. Si no hay disponible un controlador de dominio dentro de un sitio, Exchange buscará otro controlador de dominio. Esto es especialmente importante si sólo se puede tener acceso a los demás controladores de dominio de su organización a través de una WAN. Esta circunstancia podría ocasionar problemas de rendimiento e introducir un punto único de error.

• Incluya al menos dos servidores de catálogo global en cada sitio de Active Directory. Si no hay disponible un servidor de catálogo global dentro de un sitio, Exchange buscará otro servidor de catálogo global. Esto es especialmente importante si sólo se puede tener acceso a los demás servidores de catálogo global de su organización a través de una WAN. Esta circunstancia podría ocasionar problemas de rendimiento e introducir un punto único de error.

  Nota

  Si sus requisitos de rendimiento no exigen el ancho de banda que suponen dos controladores de dominio y dos servidores de catálogo global por dominio, considere la posibilidad de configurar todos los controladores de dominio como servidores de catálogo global. En este caso, todos los controladores de dominio podrán ofrecer servicios de catálogo global para la organización de Exchange 2003.

• Debe haber una relación de 4:1 entre los procesadores de Exchange y los procesadores de servidores de catálogo global, considerando que los modelos y las velocidades de los procesadores sean similares. Sin embargo, circunstancias como una mayor utilización del servidor de catálogo global, una base de datos de Active Directory mayor o grandes listas de distribución pueden hacer necesarios más servidores de catálogo global.

• En las sucursales que cuentan con más de diez usuarios, debe instalarse un servidor de catálogo global en cada ubicación que contenga servidores de Exchange. Sin embargo, para lograr redundancia es ideal implementar dos servidores de catálogo global. Si un sitio físico no dispone de dos servidores de catálogo global, puede configurar los controladores de dominio existentes como servidores de catálogo global.

• Si su arquitectura incluye varias subredes por sitio, puede aportar más disponibilidad si garantiza que tiene al menos un controlador de dominio y un servidor de catálogo global por subred. Por tanto, incluso aunque se produzca un error en un enrutador, podrá seguir teniendo acceso al controlador de dominio.

• Compruebe que el servidor al que se le ha asignado la función de maestro de infraestructura no es un servidor de catálogo global. Para obtener información acerca de la función de maestro de infraestructura, consulte el tema “Catálogo global y maestro de infraestructuras” en la Ayuda de Windows 2000 Server.

• Considere la posibilidad de supervisar la latencia de LDAP en todos los controladores de dominio de Exchange 2003 Para obtener información acerca de cómo supervisar Exchange, consulte Implementación de herramientas de supervisión de software y detección de errores.

• Considere la posibilidad de aumentar los subprocesos de LDAP de 20 a 40, dependiendo de sus requisitos. Para obtener información acerca de cómo ajustar Exchange, consulte la Guía de rendimiento y escalabilidad de Exchange Server 2003.

• Compruebe que dispone de un buen plan de copia de seguridad para los controladores de dominio.

Ejecución de Exchange 2003 en un controlador de dominio

Como recomendación, no debe ejecutar Exchange 2003 en servidores que funcionen también como controladores de dominio de Windows. En su lugar, debe configurar servidores de Exchange y controladores de dominio de Windows por separado.

Sin embargo, si su organización requiere que ejecute Exchange 2003 en un controlador de dominio, tenga en cuenta las limitaciones siguientes:

• Si ejecuta Exchange 2003 en un controlador de dominio, sólo usará ese controlador de dominio. Por tanto, si se produce un error en el controlador de dominio, Exchange no puede conmutar por error a otro controlador de dominio.
• Si los servidores de Exchange también desempeñan tareas de controlador de dominio además de atender a los equipos cliente de Exchange, esos servidores pueden experimentar una degradación del rendimiento cuando haya cargas elevadas de usuarios.
• Si ejecuta Exchange 2003 en un controlador de dominio, se pueden solapar las responsabilidades de seguridad y de recuperación de desastres de los administradores de Active Directory y de Exchange.
• Los servidores de Exchange 2003 que también son controladores de dominio no pueden formar parte de un clúster de Windows. En concreto, Exchange 2003 no permite servidores agrupados de Exchange 2003 que coexistan con servidores de Active Directory. Por ejemplo, como los administradores de Exchange que pueden iniciar sesión en el servidor local tienen acceso físico a la consola del controlador de dominio, podrían elevar sus permisos en Active Directory.
• Si su servidor es el único controlador de dominio del sistema de mensajería, debe ser también un servidor de catálogo global.
• Si ejecuta Exchange 2003 en un controlador de dominio, evite utilizar el modificador /3GB. Si utiliza este modificador, la caché de Exchange puede monopolizar la memoria del sistema. Además, como el número de conexiones de usuario debe ser reducido, no debe ser necesario utilizar el modificador /3GB.
• Puesto que todos los servicios se ejecutan bajo LocalSystem, hay más riesgo de exposición en caso de que se produzca un error de seguridad. Por ejemplo, si Exchange 2003 se está ejecutando en un controlador de dominio, un error de Active Directory que permitiera a un atacante tener acceso a Active Directory también permitiría el acceso a Exchange.
• Un controlador de dominio que ejecuta Exchange 2003 tarda bastante tiempo en reiniciarse o en apagarse (aproximadamente 10 minutos o más). Esto se debe a que los servicios relacionados con Active Directory (por ejemplo, Lsass.exe) se apagan antes que los servicios de Exchange, lo que hace que los servicios de Exchange fracasen repetidamente cuando buscan servicios de Active Directory. Una solución a este problema consiste en cambiar el tiempo de espera para los servicios con errores. Una segunda solución es detener manualmente los servicios de Exchange antes de apagar el servidor.

Disponibilidad del Sistema de nombres de dominio y el Servicio de nombres Internet de Windows

Del mismo modo que los servicios de controlador de dominio y de servidor de catálogo global, los servicios del Sistema de nombres de dominio (DNS) son fundamentales para la disponibilidad de la organización de Exchange 2003. En una red de Windows Server 2003, los usuarios buscan recursos mediante DNS y el Servicio de nombres Internet de Windows (WINS). El error de un servidor de DNS puede impedir que los usuarios encuentren el sistema de mensajería.

Para asegurarse de que la topología de Exchange 2003 incluye acceso confiable a DNS, tenga en cuenta lo siguiente:

• Asegúrese de que existe un servidor DNS secundario en la red. Si se produce un error en el servidor DNS principal, este servidor secundario debe poder dirigir a los usuarios a los servidores correctos.
• Integre zonas DNS de Windows Server 2003 en Active Directory. En esta situación, cada controlador de dominio se convierte en un servidor DNS potencial.
• Configure cada equipo cliente con dos direcciones DNS como mínimo.
• Lo ideal sería que ambos servidores DNS estuvieran en el mismo sitio que el cliente. Si los servidores DNS no están en el mismo sitio que el cliente, el servidor DNS principal debe ser el que esté en el mismo sitio que el cliente.
• Asegúrese de que la resolución de nombres y la funcionalidad de DNS funcionan correctamente. Para obtener más información, consulte en Microsoft Knowledge Base el artículo 322856, "XADM: Cómo configurar DNS para utilizar con Exchange Server".
• Antes de implementar Exchange, compruebe que DNS se ha configurado correctamente en el sitio del concentrador y en todas las sucursales.
• Exchange requiere WINS. Si bien es posible ejecutar Exchange 2003 sin habilitar WINS, no se recomienda hacerlo. El uso de WINS para resolver nombres NetBIOS aporta ventajas de disponibilidad. (Por ejemplo, en algunas configuraciones, el uso de WINS elimina el posible riesgo de que nombres NetBIOS duplicados produzcan un error de resolución de nombres). Para obtener más información al respecto, consulte en Microsoft Knowledge Base el artículo 837391, "Exchange Server 2003 y Exchange 2000 Server requieren resolución de nombres NetBIOS para funcionalidad completa".

Para obtener información acerca de cómo implementar DNS y WINS, consulte "Implementación de DNS" y "Implementación de WINS" en el Kit de implementación de Microsoft Windows Server 2003 (en inglés).

Cómo garantizar el acceso confiable a los servidores de aplicaciones para usuario de Exchange

Si su organización tiene varios servidores de Exchange, se recomienda que utilice la arquitectura de servidores de aplicaciones para usuario y servicios de fondo de Exchange. La arquitectura de aplicaciones para usuario y servicios de fondo ofrece varias ventajas de rendimiento y disponibilidad para el acceso de los clientes.

Los clientes de Internet tienen acceso a sus buzones mediante los servidores de aplicaciones para usuario. Sin embargo, en las configuraciones predeterminadas de Exchange 2003, los clientes MAPI no pueden utilizar servidores de aplicaciones para usuario; en su lugar, estos clientes tienen acceso a sus buzones directamente mediante servidores de servicios de fondo.

Cuando los servidores de aplicaciones para usuario utilizan HTTP, POP3 e IMAP4, aumenta el rendimiento porque descargan de ciertas tareas de procesamiento a los servidores de servicios de fondo.

Si desea que haya compatibilidad con MAPI, HTTP, POP3 o IMAP4, puede utilizar la arquitectura de servidores de aplicaciones para usuario y servicios de fondo de Exchange para obtener las siguientes ventajas:

• Los servidores de aplicaciones para usuario equilibran las tareas de procesamiento entre los servidores. Por ejemplo, los servidores de aplicaciones para usuario realizan procesos de autenticación, cifrado y descifrado. Esto mejora el rendimiento de los servidores de servicios de fondo de Exchange
• Mejora la seguridad del sistema de mensajería. Para obtener más información al respecto, consulte “Medidas de seguridad” más adelante en este tema.
• Para incorporar redundancia y equilibrio de carga en el sistema de mensajería puede utilizar Equilibrio de carga de red (NLB) en los servidores de aplicaciones para usuario de Exchange.

Para obtener información acerca de cómo diseñar una arquitectura de aplicaciones para usuario y servicios de fondo de Exchange 2003, consulte "Diseño de la infraestructura de Exchange" en Diseño de un sistema de mensajería de Exchange Server 2003.

Para obtener información acerca de cómo implementar servidores de aplicaciones para usuario y servicios de fondo, consulte Utilización de servidores de aplicaciones para usuario de Microsoft Exchange 2000 (en inglés). Si bien ese documento se centra en Exchange 2000, su contenido es aplicable a Exchange 2003.

Para disponer de tolerancia a errores en el sistema de mensajería, considere la posibilidad de implementar servidores de aplicaciones para usuario de Exchange que utilicen NLB. También debe configurar servidores virtuales redundantes en los servidores de aplicaciones para usuario.

Uso de Equilibrio de carga de red en los servidores de aplicaciones para usuario

Equilibrio de carga de red (NLB) es un servicio de Windows Server 2003 que ofrece compatibilidad con equilibrio de carga para aplicaciones y servicios basados en IP que requieren una escalabilidad y un rendimiento elevados. Cuando se implementa en los servidores de aplicaciones para usuario de Exchange 2003, NLB puede resolver cuellos de botella ocasionados por los servicios de aplicaciones para usuario.

En la figura siguiente se ilustra una arquitectura básica de aplicaciones para usuario y servicios de fondo que incluye NLB.

Un clúster NLB distribuye dinámicamente el tráfico IP a dos o más servidores de aplicaciones para usuario de Exchange, distribuye de forma transparente las solicitudes de los clientes entre los servidores de aplicaciones para usuario y permite que los clientes tengan acceso a sus buzones mediante un único espacio de nombres de servidor.

Los clústeres NLB son equipos que, mediante sus números, mejoran la escalabilidad y el rendimiento de lo siguiente:

• Servidores Web
• Equipos que ejecutan ISA Server (para servidores proxy y servidores de seguridad)
• Otras aplicaciones que reciben tráfico TCP/IP y del Protocolo de datagramas de usuario (UDP)

Los nodos de clúster NLB suelen tener unas configuraciones idénticas de hardware y software. Esto ayuda a garantizar que los usuarios reciben un rendimiento coherente de los servicios de aplicaciones para usuario, cualquiera que sea el nodo del clúster NLB que proporcione el servicio. Todos los nodos de un clúster NLB están activos.

Para obtener más información acerca de NLB, consulte "Diseño de Equilibrio de carga de red" e "Implementación de Equilibrio de carga de red" en el Kit de implementación de Microsoft Windows Server 2003 (en inglés).

Equilibrio de carga de red y escalabilidad

Con NLB, a medida que aumente la demanda de los servidores de aplicaciones para usuario de Exchange 2003, puede realizar un escalado vertical u horizontal. En general, si su objetivo principal es ofrecer un servicio más rápido a los usuarios de Exchange, el escalado vertical (por ejemplo, agregar procesadores adicionales y más memoria) es una buena solución. Sin embargo, si desea implementar alguna medida de tolerancia a errores en los servicios de aplicaciones para usuario, el escalado horizontal (agregar servidores adicionales) es la mejor solución. Con NLB puede realizar el escalado horizontal de hasta 32 servidores si es necesario. El escalado horizontal aumenta la tolerancia a errores ya que, si tiene más servidores en el clúster NLB, un error de un servidor afecta a menos usuarios.

Configuración de servidores virtuales de protocolo de Exchange

Cuando configure el sistema de mensajería de Exchange 2003, utilice el Administrador del sistema de Exchange para crear un servidor virtual de protocolo para cada protocolo para el que desee ofrecer compatibilidad en un servidor de aplicaciones para usuario determinado.

Para ampliar al máximo la disponibilidad y el rendimiento de los servidores de aplicaciones para usuario, tenga en cuenta las recomendaciones siguientes a la hora de configurar servidores virtuales de protocolo:

• Cuando configure NLB para los servidores de aplicaciones para usuario de Exchange 2003, debe asegurarse de que todos los servidores virtuales de protocolo de los servidores de aplicaciones para usuario NLB estén configurados con opciones idénticas.

  Importante

  Si los servidores virtuales de protocolo del clúster NLB no son idénticos, los clientes de correo electrónico pueden experimentar un comportamiento diferente, dependiendo del servidor al que se enruten.

• Si no está utilizando NLB en los servidores de aplicaciones para usuario, no cree servidores virtuales de protocolo adicionales en cada servidor de aplicaciones para usuario. (Por ejemplo, no cree dos servidores virtuales de protocolo HTTP idénticos en el mismo servidor de aplicaciones para usuario). Los servidores virtuales adicionales pueden afectar considerablemente al rendimiento y sólo deben crearse cuando no se puedan configurar correctamente servidores virtuales predeterminados.

Para obtener más información acerca de cómo configurar servidores virtuales de protocolo de Exchange, consulte la Guía de administración de Exchange Server 2003.

Para obtener información acerca del ajuste de servidores de aplicaciones para usuario de Exchange 2003, consulte la Guía de rendimiento y escalabilidad de Exchange Server 2003.

Implementación de una solución confiable de almacenamiento de servicios de fondo

Una estrategia de almacenamiento confiable es de suma importancia para lograr un sistema de mensajería tolerante a errores. Para implementar y configurar una solución de almacenamiento confiable debe estar familiarizado con lo siguiente:

• Tecnología de bases de datos de Exchange 2003
• Recomendaciones para configurar y mantener datos de Exchange
• Tecnologías de almacenamiento avanzadas como RAID y Redes de área de almacenamiento (SAN)
• Para obtener información detallada acerca de cómo diseñar e implementar una solución confiable de almacenamiento de servicios de fondo, consulte Diseño de una solución de almacenamiento de servicios de fondo confiable.

Implementación de una solución de clústeres de servidor

Al permitir la conmutación por error de recursos, los clústeres de servidor ofrecen tolerancia a errores para la organización de Exchange 2003. En concreto, los clústeres de servidor que utilizan el Servicio de Cluster Server mantienen la integridad de los datos, y ofrecen compatibilidad con conmutación por error y alta disponibilidad para aplicaciones y servicios fundamentales de los servidores de servicios de fondo, incluyendo bases de datos, sistemas de mensajería y servicios de archivos e impresión.

En la figura siguiente se ilustra un ejemplo de un clúster de cuatro nodos donde hay tres nodos activos y uno pasivo.

En los clústeres de servidor, los nodos comparten el acceso a los datos. Los nodos pueden ser activos o pasivos, y la configuración de cada nodo depende del modo de funcionamiento (activo o pasivo) y de cómo configure la conmutación por error. Un servidor que esté diseñado para realizar conmutación por error debe tener un tamaño adecuado como para asumir la carga de trabajo del nodo donde se produjo un error.

Para obtener información acerca de cómo diseñar los clústeres de servidor de Exchange, consulte Diseño de la organización en clústeres de Exchange.

Ventajas de la organización en clústeres

La organización en clústeres aporta dos ventajas principales a su organización: conmutación por error y escalabilidad.

Conmutación por error

La conmutación por error es una de las ventajas más importantes que ofrece la organización en clústeres. Si un servidor de un clúster deja de funcionar, la carga de trabajo de ese servidor se conmuta a otro servidor del clúster. La conmutación por error garantiza la disponibilidad continua de aplicaciones y datos. Las tecnologías de organización en clústeres de Windows ayudan a protegerse contra tres tipos de errores concretos:

• Errores de aplicaciones y servicios. Estos errores afectan al software de aplicación y a servicios esenciales.
• Errores del sistema y de hardware. Estos errores afectan a componentes de hardware como CPU, unidades, memoria, adaptadores de red y fuentes de alimentación.
• Errores en sitios de organizaciones que constan de varios sitios. Estos errores pueden deberse a desastres naturales, interrupciones del suministro eléctrico o interrupciones de la conectividad. Para protegerse contra este tipo de error debe implementar una solución avanzada de clústeres geográficos. Para obtener más información al respecto, consulte “Uso de varios sitios físicos” más adelante en este tema.

Al ayudar a protegerse contra estos tipos de errores, la organización en clústeres del servidor ofrece las dos ventajas siguientes al entorno de mensajería:

• Alta disponibilidad   La posibilidad de ofrecer a los usuarios finales servicios de acceso seguros al tiempo que se reducen las interrupciones no programadas.
• Alta confiabilidad   La posibilidad de reducir la frecuencia de un error del sistema.

Escalabilidad

La escalabilidad es otra ventaja que ofrece la organización en clústeres del servidor. Como puede agregar nodos a los clústeres, los clústeres de servidor de Windows son extremadamente escalables.

Limitaciones de la organización en clústeres

En lugar de proporcionar tolerancia a errores en el nivel de datos, la organización en clústeres de servidor ofrece tolerancia a errores en el nivel de aplicaciones. Cuando implemente una solución de organización en clústeres de servidor, debe implementar también unas buenas soluciones de protección y recuperación de datos para protegerse contra virus, daños y otras amenazas para los datos. Las tecnologías de organización en clústeres no pueden proteger contra errores ocasionados por virus, daños del software o errores humanos.

Organización en clústeres frente a hardware tolerante a errores

Tanto la organización en clústeres como el hardware tolerante a errores protegen el sistema frente a errores de componentes (como errores de CPU, memoria, ventilador o bus PCI). Aunque puede utilizar conjuntamente la organización en clústeres y hardware tolerante a errores como una solución completa, tenga en cuenta que los dos métodos proporcionan alta disponibilidad de distintas formas:

• La organización en clústeres puede ofrecer protección frente a un error de una aplicación o del sistema operativo. Sin embargo, un servidor independiente (no organizado en clústeres) que utilice hardware tolerante a errores (o un servidor que utilice hardware de intercambio directo, que permite agregar un dispositivo mientras el servidor está en funcionamiento) no puede ofrecer protección contra estos tipos de errores.
• La organización en clústeres le permite realizar actualizaciones o instalaciones en uno de los nodos del clúster, al tiempo que mantiene la disponibilidad de los servicios de Exchange para los usuarios. Con los servidores independientes (no organizados en clústeres) debe detener con frecuencia los servicios de Exchange para realizar estas actualizaciones o instalaciones. Para obtener información específica acerca de cómo puede mantener los servicios de Exchange mientras realiza actualizaciones o instalaciones, consulte "Cómo desconectar servidores virtuales de Exchange o recursos de Exchange" en la Guía de administración de Exchange Server 2003.

Implementación de una estrategia de supervisión

La supervisión continua de la red, las aplicaciones, los datos y el hardware es esencial para lograr una alta disponibilidad. Las herramientas y las técnicas de supervisión de software le permiten determinar el estado del sistema e identificar posibles problemas antes de que se produzca un error.

Para lograr la máxima disponibilidad, debe administrar, supervisar y solucionar problemas de los servidores y de las aplicaciones de manera coherente. Si se produce un problema, debe ser capaz de reaccionar rápidamente para poder recuperar los datos y hacer que estén disponibles en el menor tiempo posible. Para ayudarle a supervisar la organización de Exchange 2003 puede utilizar Exchange 2003 Management Pack para Microsoft Operations Manager.

Para obtener información completa acerca de Exchange 2003 Management Pack, Microsoft Operations Manager y otras herramientas de supervisión, consulte Implementación de herramientas de supervisión de software y detección de errores.

Implementación de una solución de recuperación de desastres

Para aumentar la tolerancia a errores de su organización tiene que elaborar e implementar una estrategia de copia de seguridad y recuperación bien diseñada. Si está bien preparado, podrá recuperarse de la mayoría de los errores.

Recomendaciones adicionales de nivel del sistema

Después de considerar las medidas para aumentar la tolerancia a errores en la infraestructura de Exchange 2003, considere las siguientes recomendaciones adicionales de nivel del sistema:

• Protección del entorno físico de los servidores   Tome precauciones para asegurarse de que el entorno físico está protegido.
• Medidas de seguridad   Implemente el uso de permisos, revisiones de seguridad, seguridad física del equipo, protección antivirus y soluciones para impedir correo electrónico no deseado.
• Enrutamiento de mensajes   Utilice hardware de red tolerante a errores, y configure correctamente los grupos de enrutamiento y los conectores.
• Uso de varios sitios físicos   Para proteger los datos frente a errores de sitios, refleje los datos en uno o más sitios remotos, o implemente la organización en clústeres geográfica para permitir la conmutación por error en caso de que se produzca un error en un sitio.
• Procedimientos operativos   Mantenga y supervise los servidores, utilice procedimientos estándar y pruebe los procedimientos de recuperación de desastres.
• Pruebas en laboratorio e implementaciones piloto   Antes de implementar el sistema de mensajería en un entorno de producción, pruebe el rendimiento y la escalabilidad en entornos de laboratorio y piloto.

Protección del entorno físico de los servidores

Para mantener la disponibilidad de los servidores, debe mantener unos estándares elevados para el entorno donde deben funcionar esos servidores. Para aumentar la longevidad y la confiabilidad del hardware de servidor, tenga en cuenta lo siguiente:

• Temperatura y humedad   Instale los servidores críticos en una sala preparada para tal fin; en concreto, utilice una sala en la que pueda controlar con precisión la temperatura y la humedad. Los equipos funcionan mejor a unos 21 grados Celsius. En un entorno de oficina, la temperatura no suele suponer ningún problema. Sin embargo, considere los efectos que puede tener un fin de semana largo de verano con el aire acondicionado apagado.
• Polvo o contaminantes   Siempre que sea posible, proteja los servidores y otros equipos del polvo y agentes contaminantes, y compruebe periódicamente si se ha acumulado polvo. El polvo y otros contaminantes pueden producir el cortocircuito o el sobrecalentamiento de los componentes, lo que puede ocasionar errores intermitentes. Siempre que la carcasa de un servidor esté abierta, determine rápidamente si es preciso limpiar la unidad. En tal caso, compruebe también todas las demás unidades de ese área.
• Fuentes de alimentación   Como con cualquier plan de recuperación de desastres, es mejor planear los cortes de alimentación mucho antes de que ocurran y eso implica identificar los recursos más importantes par el funcionamiento de su empresa. Siempre que sea posible, suministre alimentación eléctrica a la sala de equipos desde dos circuitos diferentes por lo menos y divida las fuentes de alimentación redundantes entre las fuentes de energía. Idealmente, los circuitos deben provenir de dos fuentes externas al edificio. Tenga en cuenta la cantidad máxima de energía que una ubicación puede proporcionar. Es posible que una ubicación pueda tener tantos servidores que no haya energía suficiente para otros servidores adicionales. Considere la posibilidad de utilizar una fuente de alimentación de reserva por si se produce una interrupción del suministro eléctrico en su centro informático. Quizás sea necesario seguir ofreciendo servicios informáticos a otros edificios del área o a otras áreas remotas geográficamente desde el centro informático. Puede utilizar sistemas de alimentación ininterrumpida (SAI) para resolver las interrupciones breves y generadores para las interrupciones más prolongadas. Cuando examine los equipos que necesitan energía de reserva durante un corte del suministro eléctrico, incluya equipos de red como los enrutadores.
• Mantenimiento de cables   Para impedir que se produzcan daños físicos en los cables, asegúrese de que los cables estén en buen estado y ordenados, ya sea mediante un sistema de administración de cables o mediante grapas. Nunca debe haber cables sueltos en un bastidor, ya que se pueden desconectar por equivocación. Si es posible, asegúrese de que todos los cables estén bien conectados en ambos extremos. Asegúrese también de que los equipos montados en bastidor tengan suficiente holgura en los cables, y de que los cables no se doblen y no estén pillados o rotos. Prepare buenos recorridos para los conjuntos de cables redundantes. Si utiliza varias fuentes de energía o comunicaciones de red, procure dirigir los cables a las carcasas desde distintos puntos. De esa forma, si un cable resulta dañado el otro puede seguir funcionando. No conecte fuentes de alimentación duales en el mismo enchufe. Si es posible, utilice tomas de alimentación o unidades SAI diferentes (idealmente, conectadas a distintos circuitos) para evitar un punto único de error.

Medidas de seguridad

La seguridad es un componente fundamental para lograr un sistema de mensajería de alta disponibilidad. Aunque hay que tener en cuenta muchas medidas de seguridad, a continuación se muestran algunas de las más importantes:

• Permisos
• Revisiones de seguridad
• Seguridad física
• Protección antivirus
• Soluciones para evitar correo electrónico no deseado

Para obtener información detallada acerca de estas y otras medidas de seguridad, consulte la Guía para reforzar la seguridad de Exchange Server 2003.

Consideraciones sobre el enrutamiento de mensajes

La topología de enrutamiento es la base del sistema de mensajería. Por tanto, debe diseñar la topología de enrutamiento teniendo en cuenta la red, el ancho de banda y los aspectos geográficos.

El enrutamiento define el modo en que Exchange transfiere los mensajes entre servidores. Al diseñar la topología de enrutamiento, es necesario comprender cómo se transfieren los mensajes dentro de Exchange y diseñar una topología que permita la transferencia más eficaz de los mensajes. También es necesario considerar las ubicaciones de los conectores con los sistemas de mensajería externos a la organización de Exchange. Un diseño cuidadoso puede contribuir a reducir el volumen del tráfico en la red y a optimizar los servicios de Exchange y de Windows.

Para garantizar que el enrutamiento de los mensajes es confiable y está disponible, tenga en cuenta las siguientes recomendaciones generales:

• Asegúrese de que la red física tiene redundancia integrada. Para obtener más información al respecto, consulte “Hardware de red” anteriormente en este tema.
• Asegúrese de que ha configurado correctamente los conectores y los grupos de enrutamiento. Por ejemplo, en algunos casos, el uso del Administrador del sistema de Exchange para configurar rutas de conectores redundantes puede limitar un punto único de error.
• Configure los conectores para asegurarse de que haya varias rutas a todos los servidores cabeza de puente.
• Si es aplicable, asegúrese de que los servidores de puerta de enlace del Protocolo simple de transferencia de correo (SMTP) sean redundantes. En los centros de datos grandes, se suele recomendar que dedique determinados servidores de Exchange 2003 sólo al tráfico SMTP entrante y saliente. Estos servidores suelen llamarse servidores de puerta de enlace SMTP o concentradores SMTP. Estos servidores son responsables de mover el correo electrónico SMTP entre los clientes y los servidores de buzones (servidores de servicios de fondo) de Exchange 2003.

Para obtener información acerca de cómo planear el diseño y la configuración de enrutamiento (incluyendo recomendaciones para crear grupos de enrutamiento y conectores), consulte Diseño de un sistema de mensajería de Exchange Server 2003.

Para obtener información acerca de cómo configurar el enrutamiento de mensajes, consulte la Guía de transporte y enrutamiento de Exchange Server 2003.

Uso de varios sitios físicos

Para mejorar la recuperación de desastres y aumentar la disponibilidad, algunas organizaciones utilizan varios sitios físicos. La mayoría de los diseños que constan de varios sitios incluyen un sitio principal y uno o más sitios remotos que reflejan el sitio principal. El nivel en el que se reflejan los componentes y los datos entre los sitios depende del SLA y de los requisitos de la empresa. Otra opción consiste en implementar clústeres dispersos geográficamente. Con los clústeres dispersos geográficamente, en caso de que se produzca un desastre, las aplicaciones de un sitio pueden conmutar por error a otro sitio diferente.

Las próximas secciones contienen más información acerca del reflejo de sitios y la organización en clústeres geográfica.

Reflejo de sitios

El reflejo de sitios implica el uso de la replicación sincrónica o asincrónica para reflejar datos (por ejemplo, bases de datos y datos de registro de transacciones de Exchange 2003) desde el sitio principal a uno o más sitios remotos.

Si se produce un error en todo el sitio principal, el tiempo necesario para poner en línea los servicios de Exchange en el sitio reflejado depende de la complejidad de la organización de Exchange, la cantidad de hardware en espera preconfigurado que tenga y el nivel de apoyo administrativo. Por ejemplo, una organización puede ser capaz de seguir un conjunto previamente diseñado de procedimientos de recuperación de desastres y poner en línea su sistema de mensajería de Exchange en menos de 24 horas. Aunque 24 horas pueda parecer mucho tiempo de inactividad, quizás pueda recuperar datos cerca del punto de error. Para obtener información acerca de la replicación sincrónica y asincrónica de datos de Exchange, consulte "Tecnologías de replicación de datos de Exchange" en Descripción general de las tecnologías de almacenamiento.

Clústeres dispersos geográficamente

Una forma más avanzada de implementar la tolerancia a errores en el nivel de sitio consiste en implementar clústeres dispersos geográficamente. Para implementar clústeres dispersos geográficamente con Windows Server 2003, utilice LAN virtuales (VLAN) para conectar las SAN a través de largas distancias.

Las configuraciones de clústeres dispersos geográficamente pueden ser complejas y los servidores organizados en clústeres sólo deben utilizar componentes compatibles con Microsoft. Debe implementar clústeres dispersos geográficamente sólo con proveedores que ofrezcan configuraciones de calidad.

Para obtener más información acerca de las soluciones de clústeres dispersos geográficamente con Exchange 2003, consulte Diseño de la organización en clústeres de Exchange.

Para obtener información acerca de Windows Server 2003 y los clústeres dispersos geográficamente, consulte Clústeres Geográficamente Dispersos en Windows Server 2003.

Recomendaciones operativas

Cuando utilice y administre el sistema de mensajería de Exchange 2003, es importante que el personal de IT utilice recomendaciones estándar de IP. Esta sección contiene recomendaciones para ampliar al máximo la disponibilidad de las aplicaciones y los equipos. (Esta información se aplica tanto a los entornos organizados en clústeres como a los que no están organizados en clústeres).

• Reduzca al mínimo o elimine la compatibilidad con varias versiones de los sistemas operativos, Service Pack y aplicaciones obsoletas
  Es difícil ofrecer un soporte técnico confiable cuando se utilizan varias combinaciones de distintas versiones de software y hardware en un mismo sistema (o en sistemas que interactúan en la red). El software, los protocolos y los controladores (y el hardware asociado) obsoletos no son prácticos cuando no son compatibles con las nuevas tecnologías. Reserve recursos y tiempo para planear, probar e instalar nuevos sistemas operativos, aplicaciones y hardware. A la hora de planear actualizaciones de software, trabaje con los usuarios para identificar las características que necesitan. Ofrezca el entrenamiento adecuado para simplificar a los usuarios las transiciones de software. En su presupuesto para software y soporte técnico, reserve fondos para actualizar aplicaciones y sistemas operativos en el futuro.

• Aísle las aplicaciones no confiables
  Una aplicación no confiable es una aplicación totalmente imprescindible para empresa pero que no cumple los estándares apropiados en cuanto a confiabilidad. Si debe trabajar con una aplicación de este tipo, puede adoptar dos enfoques básicos:

  • Quitar las aplicaciones no confiables de los servidores que sean más importantes para su empresa. Si se sabe que una aplicación no es confiable, realice los pasos necesarios para aislarla y no la ejecute en un servidor crítico para la empresa.
  • Ofrezca suficiente supervisión y utilice opciones de reinicio automático cuando sea apropiado. Una supervisión suficiente requiere la toma de instantáneas de medidas importantes del rendimiento del sistema a intervalos periódicos. Puede configurar el reinicio automático de una aplicación o de un servicio mediante el complemento Servicios. Para obtener información acerca de los servicios de Windows, consulte “Introducción a Servicios” en la Ayuda de Windows Server 2003.

• Utilice hardware actual estándar
  El hardware incompatible puede causar problemas de rendimiento y pérdida de datos. Mantenga y siga un estándar de hardware para los sistemas nuevos, las piezas de repuesto y las piezas de sustitución.

• Prevea los requisitos futuros de capacidad
  La planificación de la capacidad es fundamental para el éxito de los sistemas de alta disponibilidad. Para entender cuánta capacidad adicional existe actualmente en el sistema, estudie y supervise el sistema durante las cargas pico.

• Mantenga una lista actualizada de procedimientos operativos
  Cuando se corrija un problema raíz del sistema, asegúrese de quitar todos los procedimientos anticuados de las programaciones de operación y soporte técnico. Por ejemplo, cuando se sustituye o se actualiza software, algunos procedimientos pueden ser innecesarios o dejar de ser válidos. Preste especial atención a los procedimientos que puedan haberse convertido en tareas rutinarias. Asegúrese de que todos los procedimientos sean necesarios y no soluciones temporales de problemas para los que no se haya encontrado su causa.

• Realice las tareas de supervisión adecuadas
  Si no supervisa adecuadamente su sistema de mensajería, quizás no pueda identificar los problemas antes de que se conviertan en críticos y produzcan errores del sistema. Sin la supervisión, un error de una aplicación o de un servidor puede ser la única notificación de un problema.

• Determine la naturaleza del problema antes de reaccionar
  Si el personal de operaciones no está entrenado y dirigido para analizar los problemas detenidamente antes de reaccionar, puede pasar mucho tiempo respondiendo incorrectamente ante un problema. Puede que tampoco esté utilizando eficazmente las herramientas de supervisión en el momento crucial desde que se detectan los primeros síntomas de un problema hasta que se produce un error real.

• Trate la causa raíz de los problemas en lugar de tratar los síntomas
  Cuando se produce un error inesperado o cuando se realiza un mantenimiento preventivo a corto plazo, el tratamiento de los síntomas es una estrategia eficaz para restaurar los servicios. Sin embargo, el tratamiento de los síntomas que se agrega a los procedimientos operativos estándar puede resultar imposible de administrar. El personal de soporte técnico puede verse desbordado por los tratamientos de síntomas y quizás no pueda reaccionar correctamente ante nuevos errores.

• Evite detener y reiniciar los servicios y los servidores para poner fin a las condiciones de error
  Algunas veces puede ser necesario detener y reiniciar un servidor. Sin embargo, si este proceso corrige temporalmente un problema pero no resuelve su causa, puede crear otros problemas adicionales.

Pruebas en laboratorio e implementaciones piloto

Antes de implementar una solución nueva, tanto si se trata de hardware tolerante a errores como de hardware de red, una herramienta de supervisión de software o una solución de Organización en clústeres de Windows, debe probarla exhaustivamente antes de implementarla en un entorno de producción. Después de probar la solución en un laboratorio aislado, pruébela en una implementación piloto en la que sólo se vean afectados unos pocos usuarios y, a continuación, haga los ajustes necesarios en el diseño. Cuando esté satisfecho con la implementación piloto, realice una implementación completa en el entorno de producción.

Dependiendo del número de usuarios que haya en su organización de Exchange, quizás desee realizar la implementación completa en varias fases. Después de cada fase, compruebe que el sistema puede atender a la mayor carga de procesamiento que suponen los usuarios adicionales antes de implementar el siguiente grupo de usuarios. Para obtener información completa acerca de cómo configurar entornos de prueba y piloto, consulte “Diseño de un entorno de prueba” y “Diseño de un proyecto piloto” en el Kit de implementación de Microsoft Windows Server 2003 (en inglés).

Herramientas de diseño de capacidad de Exchange

Para averiguar cuántos servidores de Exchange se necesitan para administrar la carga de usuarios, utilice las siguientes herramientas de diseño de capacidad:

• Exchange Server Load Simulator 2003 (LoadSim)
• Herramienta Exchange Server Stress and Performance (ESP)
• Jetstress

Exchange Server Load Simulator 2003

Con Exchange Server Load Simulator 2003 (LoadSim) puede simular la carga de clientes MAPI en Exchange. Para simular la carga, ejecute las pruebas de LoadSim en equipos cliente. Estas pruebas envían solicitudes de mensajería al servidor de Exchange, lo que genera una carga en el servidor.

Utilice el resultado de estas pruebas de la forma siguiente:

• Para calcular el tiempo de respuesta del equipo cliente para la configuración del servidor con la carga del cliente
• Para estimar el número de usuarios por servidor
• Para identificar los cuellos de botella del servidor

Puede descargar LoadSim 2003 desde el sitio Web de Descargas para Exchange Server 2003.

Herramienta Exchange Server Stress and Performance

Exchange Server Stress and Performance (ESP) 2003 es una herramienta de rendimiento y sobrecarga altamente escalable para Exchange. Simula un gran número de sesiones de cliente al obtener acceso simultáneamente a uno o varios servicios del protocolo. Las secuencias de comandos controlan las acciones que realiza cada usuario simulado. Las secuencias de comandos contienen la lógica necesaria para la comunicación con el servidor. A continuación, los módulos de prueba (DLL) ejecutan estas secuencias de comandos. Los módulos de prueba conectan un servidor a través de los protocolos de Internet, de llamadas a las interfaces de programación de aplicaciones (API), o a través de interfaces como OLE DB.

ESP es modular y extensible, y actualmente cuenta con módulos para la mayoría de los protocolos de Internet, incluidos los siguientes:

• WebDAV
• Protocolo de acceso a correo de Internet versión 4rev1 (IMAP4)
• Protocolo ligero de acceso a directorios (LDAP)
• OLE DB
• Protocolo de oficina de correo versión 3 (POP3)
• Protocolo simple de transferencia de correo (SMTP)

Puede descargar ESP 2003 en https://go.microsoft.com/fwlink/?linkid=27881.

Jetstress

Exchange 2003 es una aplicación que hace un uso intensivo del disco. Para funcionar correctamente, Exchange necesita un subsistema de disco rápido y confiable. Jetstress (Jetstress.exe) es una herramienta de Exchange que ayuda a los administradores a comprobar el rendimiento y la estabilidad del subsistema de disco antes de implementar servidores de Exchange en un entorno de producción. Para obtener más información acerca de Jetstress y el almacenamiento de servicios de fondo de Exchange, consulte Diseño de una solución de almacenamiento de servicios de fondo confiable.

Puede descargar Jetstress en https://go.microsoft.com/fwlink/?linkid=27883.