¿Por qué las grandes instalaciones de Exchange requieren tiempo de inactividad para el mantenimiento?

He utilizado varios proveedores externos de Exchange de primer nivel a lo largo de los años, y todos ellos han tenido tiempos de inactividad programados regularmente para el mantenimiento de rutina (aproximadamente una vez al mes). Me pregunto qué tiene Exchange que hace que sea imposible evitar tiempos de inactividad de esta naturaleza. ¿Es realmente imposible mantener un tiempo de actividad 24x7 o simplemente costoso y por qué?

Las actualizaciones de Windows y Exchange siempre requieren reinicios para finalizar la instalación, así que eso es parte de ello. Con una buena planificación y una configuración adecuada (equilibradores de carga y agrupación) puede mantener un tiempo de actividad 24x7 para que el correo electrónico esté siempre disponible en un servidor.

Sin embargo, en el lado del cliente, siempre hay una breve interrupción (5-30 segundos) ya que Outlook descubre que el servidor CAS al que está conectado está desconectado y la detección automática lo cambia a otro. Por lo general, aparece el mensaje "El administrador de Exchange ha realizado un cambio que requiere que reinicie Outlook" cuando esto sucede.

No es una interrupción prolongada, pero cuenta como una interrupción, por eso debe programar el tiempo de mantenimiento para hacerlo. También existe la posibilidad de que algo salga mal durante el período de mantenimiento, por lo que para CYA debe programarlo.

EDITAR: Entonces descubrí que si coloca un equilibrador de carga frente a sus servidores CAS, no recibirá el mensaje "El administrador de Exchange ha realizado un cambio ..." en Outlook. Aún tendrá una breve interrupción cuando el equilibrador de carga lo cambie a un servidor CAS activo.

Larga historia corta ... No estás utilizando ese gran proveedor.

No hay ninguna razón por la que necesite programar el tiempo de inactividad regular de un entorno de Exchange (aunque programar ventanas de mantenimiento regulares siempre es una buena idea). Especialmente con Exchange 2010. Siempre que su redundancia se planifique e implemente correctamente, todo fluirá. Red redundante, almacenamiento redundante, servidores redundantes.

Probablemente no obtendrá esto utilizando un proveedor de $ 3 / mes. No revendo buzones de Exchange de $ 3 / mes. La mayoría de mis razones para recomendar un acuerdo alojado de Exchange con la importancia del correo electrónico y el tiempo de actividad. Tiene que pagar más por un proveedor que no baja todo el tiempo, pero el retorno de la inversión tiene sentido.

Nuestro proveedor envía correos electrónicos para cada mantenimiento programado. Recibimos al menos uno de ellos al mes. El 99% de ellos básicamente lee: "Estamos haciendo mantenimiento en nuestros servidores entre las 2 a.m. y las 2:15 a.m.

Si está buscando un tiempo de actividad del 100% sin 30 segundos de conmutación por error, simplemente no lo encontrará en ninguna parte. No con Exchange, ni con Google Apps, ni con Domino. El 100% de tiempo de actividad no existe. Siempre se necesitarán ventanas de mantenimiento y las failovers aún requieren tiempo (incluso si ese tiempo es breve).

Por lo tanto, busque un nuevo proveedor que le cueste más pero que le brinde el tiempo de actividad que necesita.

Mantenga la redundancia N + 1 para literalmente cada parte de la red para garantizar que ningún tiempo de inactividad por mantenimiento costará más; suficiente más que el servicio ya no sería competitivo en precio. La mayoría de las empresas son muy tolerantes con un tiempo de inactividad mínimo programado. Esto no es exclusivo de Exchange, casi todos los proveedores de hosting, de cualquier tipo, con los que he tratado hace aproximadamente lo mismo.

En el caso de Exchange, se reducirá una vez al mes (al menos) para Patch Tuesday.

El único mantenimiento de rutina que Exchange necesita es parchear los servidores, lo que en un entorno construido adecuadamente no debería crear ningún tiempo de inactividad: incluso con solo dos servidores, puede mantener uno de ellos activo mientras parchea y reinicia el otro. Tomar copias de seguridad no crea ningún tiempo de inactividad, y probar las restauraciones es algo que debe hacerse en un entorno DR, no en servidores en vivo. Realmente no entiendo qué es este "mantenimiento de rutina" o por qué debería ser necesario.

Por supuesto, no digo que garantizar un 99% de tiempo de actividad sea fácil; los problemas suceden, incluso en los mejores y más caros entornos. Lo que digo es que no hay ninguna razón para eliminar un sistema de Exchange para el "mantenimiento de rutina". A menos que realice desfragmentaciones rutinarias fuera de línea de sus bases de datos ... algo que nadie en su sano juicio ya debería estar haciendo (pero aún así ...).

No hay nada en Exchange que lo haga inherentemente poco confiable o propenso a caer ... de hecho, diría que se aplica lo contrario. Depende de cómo estén configurados los proveedores para proporcionar su servicio de Exchange .

Uno o más servidores pueden proporcionar un servicio : los principales sitios web, sistemas de correo electrónico (por ejemplo, gmail, hotmail, etc.) son proporcionados por grupos de servidores diseñados para permitir que algunos de los servidores que alojan el servicio estén fuera de línea sin afectar la disponibilidad del servicio

Si los servidores que brindan el servicio se basan en un sistema que admite alta disponibilidad (por ejemplo, agrupación en clúster), entonces es posible que algunos de los servidores que brindan el servicio estén desconectados sin desconectarlo.

Esa es la teoría ... y se puede hacer que la teoría funcione en la práctica. La pregunta es cuánto está dispuesto a gastar el proveedor en hardware, diseño de sistemas y soporte (el costo de pasar del 99.99% disponible al 99.999% disponible es mucho mayor que el costo de pasar del 99% al 99.9% disponible, por ejemplo) . En el caso de un servicio alojado, esto se convierte rápidamente en una cuestión de cuánto están preparadas las personas para pagar por el servicio.

Para un proveedor, esto puede convertirse rápidamente en un costo prohibitivo, y cuando se dispara por una disponibilidad muy alta, incluso cantidades muy pequeñas de tiempo de inactividad pueden afectar sus estadísticas .