.net - primera - Actualización de una aplicación con 100% de tiempo de actividad
importancia de las actualizaciones (5)
En una entrevista anterior, me preguntaron cómo iba a escribir un servicio de Windows de misión crítica que debe mantener el tiempo de actividad del 100%, 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 entrada. 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 acerca de 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 construido algo con requisitos similares? ¿Qué soluciones usaste? ¿Qué no funciona? ¿La reflexión es una opción utilizable?
.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. Aún necesita descargar el dominio de aplicación antes de poder cargar las nuevas versiones, pero los otros dominios de aplicación aún 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.
100% de tiempo de actividad? "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. "... mantener el 100% de tiempo de actividad, ser muy receptivo y también ser actualizable ...": se proporcionó una métrica para el tiempo de actividad, pero ninguna para la capacidad de respuesta.
La latencia es un problema por el 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.
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: estas mediciones se aplican al tiempo de inactividad no programado , como en las 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 podría 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.
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.
Ok, poca historia, trabajo en Wireless Telecom, donde nuestras plataformas requieren un tiempo de actividad absoluto, y habiendo visto todas las diferentes estrategias, definitivamente no deberías utilizar un enfoque basado en software, agrega complejidad de software, donde todo lo que tienes que 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 equilibrador de carga de hardware. En el trabajo tenemos fundiciones y todas nuestras novedades están en equilibrio de carga de Cisco Ace.
Entonces, lo que necesita son dos equilibradores de carga de Cisco, configurar 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 grupo 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 la aplicación o las latencias en la red, el tipo está en quiebra, porque utiliza el equipo de Cisco adecuado, las latencias en un enlace de concierto son de microsegundos, y no será su punto débil.
Buena suerte.