Tenemos un grupo de 75 nodos Win2k3 trabajando en un grupo de computación de grano grueso. El clúster está detrás de una montaña de firewalls y reside en su propia VLAN. En el clúster se ejecutan trabajos de todos los tamaños y tipos y todos los ejecutables que se ejecutan están hechos a medida.
(ed: notas adicionales sobre nuestros ejecutables)Los trabajos varían de 30 segundos a 7 días de duración y pueden contener un ejecutable o 2000 subtrabajos (de corta duración). Obviamente estamos tratando de evitar la situación en la que nuestro departamento de TI programa un reinicio durante un trabajo de producción de 7 días.
Tenemos un software de programación que se adapta a todas las tareas normales para un clúster de grano grueso y podemos controlar qué máquinas están activas para su envío, etc. Si WSUS fuera de alguna manera programable (o el cliente pudiera indicar su disponibilidad para apagar), podríamos coordinar los dos sistemas y ayudar.
Actualmente, el calendario de parches es el domingo posterior al supermartes, independientemente de lo que se esté ejecutando en el clúster. Tenemos que solicitar una exención cada vez que queremos retrasar la aplicación de parches a una máquina para un trabajo de producción de larga duración. Básicamente, si bien nuestro grupo es responsable de las máquinas, tenemos poco control sobre el programa de parches de TI.
- ¿Es sensato aplicar parches mensualmente con el cronograma de MS para un clúster de Windows de producción?
- ¿Hay enlaces de software en WSUS donde podríamos decir "no reinicie todavía"?
Respuesta1
1. ¿Es sensato aplicar parches mensualmente según el cronograma de MS para un clúster de Windows de producción?
Sí, sin embargo, un clúster no debería tener ningún tiempo de inactividad asociado con un parche, ya que debería transferir los trabajos a otro nodo. NO aplicaría un parche a todo el clúster al mismo tiempo (eso sería una locura).
2. ¿Hay enlaces de software en WSUS donde podríamos decir "no reinicie todavía"?
No hay forma de que los usuarios finales detengan una actualización de WSUS o reinicien, pero me parece que tiene un problema de comunicación real entre su grupo y el grupo de TI; sin embargo, debería poder perder 1 nodo a la vez con poco impacto en la producción.
Respuesta2
Al utilizar Config Mgr para administrar la implementación de actualizaciones, puede evitar que los servidores se reinicien. Por lo tanto, se aplican las actualizaciones (pero es posible que no entren en vigor hasta que se reinicie) y TI tendrá informes que muestran los servidores que están pendientes de reiniciar. Pueden brindarle fácilmente esta lista y espero que pueda programar fácilmente los reinicios de nodos particulares sin demasiadas interrupciones. TI puede tener fácilmente una implementación a prueba de fallas (con reinicios forzados) y también un plazo de entrega prolongado, de modo que esto finalmente forzará las actualizaciones y reinicios en caso de que no cumpla con su parte del trato.
Para las implementaciones de actualización estándar, TI (y usted) probablemente querrán plazos muy cortos para una implementación totalmente silenciosa (implementación sin reinicio) y también una implementación con plazos un poco más largos que no sea silencioso, por lo que verá una notificación si inicia sesión en el servidor. Ninguna de estas implementaciones debería forzar el reinicio.
Aún así, es posible que te encuentres con una situación en la que algo falla porque una biblioteca u otro componente de código se actualizó mientras no estaba en uso y luego se usa antes de que el reinicio haga que el resto de las actualizaciones surtan efecto.
Esta es una manera eficiente de obtener lo que usted y TI desean y cada uno de ustedes tiene cierta visibilidad de lo que está sucediendo. El informe de qué servidores se encuentran en qué estado según las implementaciones también es realmente útil para ambos.
Respuesta3
Parece que su departamento de TI le está dando mucha actitud de "hablar con la mano". Debe sentarlos (¿o sobornarlos con cerveza?), explicarles su situación y ver si pueden hacer algo como crear un servidor WSUS posterior con aprobaciones de parches manuales.
Todas las configuraciones para WSUS se establecen mediante políticas de grupo, que se establecen en el directorio activo a nivel de dominio o unidad organizativa. Si los servidores están en el dominio corporativo sin una unidad organizativa separada, entonces obtienen lo que todos los demás obtienen, lo cual no parece apropiado.
Si no puede resolver el problema con su departamento de TI, ¿eliminar las computadoras del dominio?