¿Cómo se instalan las actualizaciones de seguridad críticas en los sistemas que no puedes permitirte reiniciar pero la actualización requiere un reinicio? Por ejemplo, los servicios / negocios que se requieren para funcionar 24x7 con cero tiempo de inactividad, por ejemplo. Amazon.com o Google.
Existen diferentes utilidades en diferentes sistemas operativos que permiten la aplicación de parches en el código en ejecución. Un ejemplo de esto sería kpatch y livepatch de Linux permiten parchear el kernel en ejecución sin interrumpir sus operaciones. Sus capacidades son limitadas y solo pueden realizar cambios triviales en el kernel, pero a menudo esto es suficiente para mitigar una serie de problemas de seguridad críticos hasta que se pueda encontrar el tiempo para realizar una corrección adecuada. Este tipo de técnica en general se llama actualización dinámica de software .
Debo señalar, sin embargo, que los sitios que prácticamente no tienen tiempo de inactividad ( alta disponibilidad ) no son tan confiables debido a Live-patching, pero debido a la redundancia. Cada vez que se desactiva un sistema, habrá una serie de copias de seguridad que pueden comenzar inmediatamente a enrutar el tráfico o procesar las solicitudes sin demora. Hay una gran cantidad de técnicas diferentes para lograr esto. El nivel de redundancia proporciona un tiempo de actividad significativo medido en nines . Un tiempo de actividad de tres nueve es del 99.9%. El tiempo de actividad de cuatro nueve es de 99.99%, etc. El "santo grial" es de cinco nueves, o el tiempo de actividad de 99.999%. Muchos de los servicios enumerados tienen cinco nueve disponibilidad debido a sus sistemas de copia de seguridad redundantes en todo el mundo.
Vi una presentación en una conferencia de seguridad realizada por un empleado de Netflix. Ellos no parchean en absoluto. En cambio, cuando se requiere un parche, se ponen de pie nuevas instancias y luego eliminan las que no están parcheadas. Ellos están haciendo esto casi constantemente. Lo llaman implementación rojo-negro .
La respuesta corta es:
Se reinician.
Parece que asumes que Amazon y Google se ejecutan en un solo servidor, y si se reinicia, todo el sitio / servicio está inactivo. Esto está muy lejos de la verdad: los servicios grandes normalmente se ejecutan en muchos servidores que funcionan en paralelo. Para obtener más información, consulte técnicas como agrupamiento , balanceo de carga y failover .
Google, por ejemplo, tiene en una docena de centros de datos en todo el mundo , y cada uno tiene una gran cantidad de servidores (las estimaciones son 100,000-400,000 servidores por centro ).
En dichos entornos, las actualizaciones (tanto las actualizaciones de características como las de seguridad) se instalan normalmente como implementaciones móviles :
Hay otras opciones, como la aplicación de parches en caliente, pero no se utilizan con tanta frecuencia en mi experiencia, al menos no en los sitios web grandes típicos. Vea la respuesta del bosque para más detalles.
Puede consultar " Actividades de implementación " en "Implementación del software". Un método común es utilizar un equilibrador de carga delante de sus servicios y redirigir el tráfico en consecuencia. En una técnica llamada "implementación azul-verde", redirige el tráfico de los servidores "azules" a los "verdes". Esto no tiene ningún tiempo de inactividad por parte del usuario, siempre que la aplicación pueda manejar esto correctamente, por ejemplo. a través de servicios sin estado.
Diga que su aplicación ejecuta v1 en el servidor azul y su equilibrador de carga dirige el tráfico allí. Puede actualizar el servidor verde (que no recibe ningún tráfico) a v2. A continuación, reconfigure el equilibrador de carga para dirigir el tráfico al servidor verde. Por lo tanto, ha actualizado de v1 a v2 sin tiempo de inactividad.
También puede utilizar la técnica azul-verde como parte de la prueba. Por ejemplo, configura el equilibrador de carga para dirigir el 95% del tráfico al servidor azul (v1) y el 5% al servidor verde (v2). De esta manera, puede probar su nueva versión, con menos tráfico y con menos impacto en los usuarios en caso de que tenga errores.
Es bastante fácil cuando las cosas están agrupadas y puestas en proxy. Debido a que tiene muchos nodos capaces de hacer el mismo trabajo (o varios en el caso de repositorios de datos como motores de búsqueda, sistemas de archivos Hadoop, etc.)
Haz una búsqueda en la web. Usted golpea www.altavista.com. La entrada de DNS enumera media docena de direcciones IP y su cliente encuentra una al azar. Cada IP es un enrutador de Cisco, que se transmite a uno de los 8 servidores físicos front-end (48 en total) en las direcciones IP internas. Ese servidor normaliza su consulta (elimina los espacios en blanco, etc.) y luego toma un hash MD5. El MD5 decide cuál de los 300 servidores proxy a los que va la consulta. Esa consulta se envía al proxy a través de un protocolo estándar como SOAP.
Los servidores front-end son intercambiables porque manejan solo las demandas transitorias de una sola consulta. Fuera del peor de los casos, un cliente obtiene su consulta abandonada. Utiliza los datos de RRD u otra recopilación de datos para vigilar cuando un servidor de aplicaciones para el usuario comienza a fallar y redirecciona su tráfico a un servidor en espera. Lo mismo se puede decir de los enrutadores de Cisco.
El proxy primero comprueba su caché . Para un golpe de caché, realiza la fusión de localización y envía la respuesta de vuelta; hecho. Si se trata de una "falta de memoria caché", el proxy envía la consulta a los grupos de búsqueda.
Si un proxy falla, otra máquina física puede ser intercambiada por ese proxy. Es un poco más crítico ahora, porque los proxies no son intercambiables; cada uno "posee" una pequeña porción del espectro de resultados de búsqueda. Entonces, si la máquina 0x0000-0x00d9 deja de funcionar, el sustituto debe saber que debe intervenir en ese rango. Y lo que es peor, esa máquina sustituta tendrá un caché vacío, por lo que cada consulta de búsqueda será un error de caché . Eso aumentará la carga en los grupos de búsqueda correcto en un pequeño bit por proxy derribado . Eso significa que si rebotas todos los proxies al mismo tiempo, no lo hagas durante las horas pico de búsqueda !
Los grupos de búsqueda tienen capas y redundancia similares, por supuesto, y cada segmento de la base de datos de búsqueda reside en varios nodos, por lo que si un nodo falla, otros nodos pueden servir esa porción de los resultados.
Me estoy centrando en el proxy como ejemplo. La comunicación se realiza a través de SOAP, la comunicación se realiza a través de un protocolo similar de alto nivel. Los datos que entran y salen de ella son transitorios, excepto el caché, que es importante para equilibrar la carga de clústeres del motor de búsqueda. El punto es que puede intercambiarse instantáneamente en cualquier momento, con el peor de los resultados de algunas búsquedas. Eso es algo que el servidor de aplicaciones para el usuario notaría, y simplemente podría enviar su consulta nuevamente, para cuando el nuevo proxy esté listo.
Entonces, si tiene 300 proxies y un proxy tarda una media hora en recuperar su caché, y puede soportar que la carga del motor de búsqueda aumente un 20%, entonces puede intercambiar 1 proxy cada 30 segundos, por lo que cualquier período de 30 minutos deslizante, 60 proxies (20%) están reconstruyendo cachés. Suponiendo que hay incluso una necesidad urgente de ir que rápido.
Ese ejemplo tarda 2-1 / 2 horas en implementarse, y si una amenaza emergente requiere una respuesta más rápida, entonces soportas el dolor de la falta de más caché, o bajas tu servicio lo suficiente como para parchear (pero en la búsqueda ejemplo del motor que faltan en la memoria caché seguirá siendo un problema cuando vuelva a subir. He visto los gráficos RRD después de una recarga de emergencia de la base de datos y la descarga de la memoria caché necesaria, es algo que debe ver.)
Por supuesto, normalmente el proceso se puede parchear, detener y reiniciar sin un reinicio completo. He visto un tiempo de actividad de 2 años en nodos de producción.