Actualizando una aplicación con 100% uptime

Question

En una entrevista anterior, me preguntaron cómo escribiría un servicio de Windows de misión crítica que debe mantener el 100% de tiempo de actividad, ser muy receptivo y también ser actualizable. El servicio se describió como una aplicación basada en la comunicación remota que toma las solicitudes, realiza cálculos y envía una respuesta.

Mi solución fue tener un servicio muy genérico que simplemente actúa como una puerta de enlace. Este servicio nunca se detendrá. Pondría en cola las solicitudes y las reenviaría a otro servicio en un dominio de aplicación separado que realmente manejaría la solicitud. Tendría que haber al menos dos de estos servicios de manejo, por lo que uno podría reducirse para actualizarse mientras que el otro respondería a las solicitudes entrantes. Las interfaces entre los servicios incluirían una capacidad de handshake para ver si un servicio se estaba ejecutando. Existiría un tiempo de espera muy pequeño, por lo que si un servicio fuera completo, no retendría la solicitud. También enfaticé el punto de que esta solución podría escalar bien ya que podría agregar más de estos servicios en diferentes cajas.

El entrevistador no estaba demasiado loco con esta idea debido a problemas relacionados con la latencia entre la comunicación entre los dominios de la aplicación e incluso a través de la red. Dije que para una aplicación de misión crítica debe establecer una infraestructura sólida como el software solo no puede ser la respuesta. También dijo que actualmente tienen un sistema implementado usando la reinserción. Pensé en cargar ensamblajes en un dominio de aplicación y ver un directorio para cambios de ensamblaje, pero esto parece demasiado propenso a errores.

¿Alguien ha desarrollado algo con requisitos similares? ¿Qué soluciones usaste? ¿Qué no funciona? ¿La reflexión es una opción utilizable?

Answer 1

.Net tiene soporte integrado para actualizar ensamblajes mientras están en uso. Se llama Shadow Copy y efectivamente copia los ensamblajes en un directorio separado antes de cargarlos. Todavía necesita descargar el dominio de aplicación antes de poder cargar las nuevas versiones, pero los otros dominios de aplicación todavía pueden usar las versiones anteriores del ensamblaje. De esta forma, un dominio de aplicación puede atender las solicitudes mientras se carga el nuevo dominio de aplicación. Esta es también la forma en que IIS y ASP.Net manejan las cosas.

Answer 2

100% uptime? "Cinco nueves" significa 315 segundos de tiempo de inactividad por año. Si pudieras manejar eso, lo estarías haciendo muy bien.

Suena como una pregunta de entrevista imposible. "... mantenga un 100% de tiempo de actividad, sea muy receptivo y también actualizable ...": se proporcionó una métrica para el tiempo de actividad, pero ninguna para la capacidad de respuesta.

La latencia es un problema que vale la pena preocuparse, pero luego dijeron que era una aplicación remota, por lo que no se puede escapar de ella. Creo que el entrevistador podría haber estado en desacuerdo por sí mismo, tal vez para ver cómo lo manejarías.

Answer 3

Spring dm Server afirma ser capaz de realizar implementaciones/anulaciones de los paquetes OSGi en caliente. Si el hardware puede permanecer activo el tiempo suficiente, podrá actualizar la aplicación sin tener que bajar el servidor. Si esto funciona, se convertirá en una característica estándar para todos los servidores de aplicaciones Java EE.

Answer 4

No existe el 100% de tiempo de actividad. Incluso los mejores sistemas miden el tiempo de inactividad como "5 nueves", lo que significa un 99.999% de tiempo de actividad.

Además, un punto clave: esta medida se aplica a tiempo de inactividad, como en fallas. No incluye el momento en que reduce el sistema a propósito para el mantenimiento programado.

En cualquier caso, el objetivo es instalar/actualizar el software sin incurrir en tiempo de inactividad, programado o no.Si el servidor web no admite la recarga dinámica de forma nativa, su solución parece correcta, pero creo que está integrada en muchos servidores actualmente. Es decir, solo necesitaría colocar sus nuevos archivos en el servidor y automáticamente vería que algo había cambiado y comenzaría a usarlos.

Sin embargo, dependiendo de la naturaleza del cambio que pueda causar problemas con el estado de la sesión. Es decir, las sesiones de usuario existentes podrían terminar con objetos almacenados en la sesión que no son compatibles con su nuevo código. De nuevo, posiblemente los servidores sean lo suficientemente inteligentes como para mantener copias almacenadas en caché del código original hasta que todas las sesiones que usan el código anterior hayan finalizado, pero tal vez deba manejarlo usted mismo. Su enfoque de "servidor oculto" debería manejarlo bien.

Answer 5

Bueno, poco de fondo, trabajo en Wireless Telecom, donde nuestras plataformas requieren un tiempo de actividad absoluto, y habiendo visto todas las diferentes estrategias, definitivamente no se debe usar un enfoque basado en software, agrega complejidad de software, donde todo lo que necesita hacer es agregar algo de hardware.

Como pidieron una actualización sin hit, debe tener un sistema redundante, y la mejor manera absoluta de que una aplicación de servidor sea redundante es utilizando un hardware de carga-balanceador. En el trabajo tenemos fundiciones y todas nuestras novedades están en equilibrio de carga de Cisco Ace.

Así que lo que necesita son dos equilibradores de carga de Cisco, configure HSRP entre ellos para conmutación por error entre los equilibradores de carga. Puede ser muy agresivo con la configuración de conmutación por error, pero en nuestra experiencia, ser demasiado agresivo con estos puede provocar fallas de conmutación de servicio innecesarias. Además, asegúrese de desactivar proxy-arp (le ahorrará angustia, ya que Cisco lo tiene activado por defecto).

Ahora, usted tiene un clúster de servidores de aplicaciones ¿verdad? Por lo tanto, tiene los tiempos de respuesta de la aplicación ping balanceador, puerto ping y monitor de carga. Todo lo que necesita es al menos dos servidores, pero puede agregar más más tarde (¿dónde está el plan de capacidad?). Así que ahora viene la actualización sin hit, durante la ventana de mantenimiento, desde el equilibrador de carga puede administrar uno de los servidores. Pero el equilibrador de carga puede hacer las administraciones wikid realmente donde permanecen las conexiones actuales hasta que terminan de forma natural.

En este estado, todas las solicitudes van al segundo servidor, y usted tiene todo el tiempo del mundo para hacer lo que quiera con el servidor que está actualizando. Como realmente, ¿por qué escribir una aplicación que tenga una aplicación de recarga de dominio de aplicación elegante, cuando tendrá que reiniciar el servidor cada 3 meses para aplicar un parche de Windows crítico de todos modos? Simplemente deposite el dinero en efectivo para el hardware, y tenga algo que funcione correctamente el 100% del tiempo, y puede ponerlo en el rango de esos 5x9 incluso con los problemas no planificados.

Ahora aquí está el siguiente paso, la redundancia geográfica. Cisco tiene un producto de equilibrio de carga que puede realizar un equilibrio de carga geográfica, pero nunca lo he visto. El mejor modelo geofágico que he visto se basa realmente en la aplicación solicitante. Esta no es una actualización sin hitless, pero es absolutamente confiable. Lo que hace, es en la aplicación solicitante configurar una dirección IP del servidor primario y de conmutación por error. La aplicación en sus solicitudes ve si el servidor deja de estar disponible, iniciará la misma solicitud al standby, que en este caso podría estar en la misma sala de servidores o en la ubicación de la copia de seguridad. Ideal sería una combinación, donde la aplicación puede apuntar a una IP virtual equilibradora de carga en una ubicación, o la ubicación de la copia de seguridad, y puede usar la equilibradora de carga para mantener el 100% en cada ubicación.

Además, si le preocupan las latencias entre los dominios de aplicación, o latencias en la red, el tipo está en crack, causa el uso del equipo de Cisco adecuado, las latencias en un enlace de concierto son microsegundos, y no serás tú punto débil.

Buena suerte.