Temos um cluster de 75 nós Win2k3 funcionando em um cluster de computação de granulação grossa. O cluster está atrás de uma montanha de firewalls e reside em sua própria VLAN. Tarefas de todos os tamanhos e tipos são executadas no cluster e todos os executáveis em execução são personalizados.
(ed: notas adicionais sobre nossos executáveis)Os trabalhos variam de 30 segundos a 7 dias de duração e podem conter um executável ou 2.000 subtrabalhos (de curta duração). Obviamente estamos tentando evitar a situação em que nossa TI agenda uma reinicialização durante um trabalho de produção de 7 dias.
Temos um software de agendamento que acomoda todas as tarefas normais para um cluster de granulação grossa e podemos controlar quais máquinas estão ativas para envio, etc. Se o WSUS fosse de alguma forma programável (ou o cliente pudesse indicar sua disponibilidade para desligamento), poderíamos coordenar os dois sistemas e ajudar.
Atualmente, a programação do patch é no domingo após a Superterça, independentemente do que está em execução no cluster. Temos que pedir uma isenção sempre que quisermos adiar a correção de uma máquina para um trabalho de produção de longa duração. Basicamente, embora nosso grupo seja responsável pelas máquinas, temos pouco controle sobre o cronograma de patches da TI.
- A correção mensal com o cronograma da MS é sensata para um cluster de produção do Windows?
- Existem ganchos de software no WSUS onde poderíamos dizer “por favor, não reinicie ainda”?
Responder1
1. A aplicação de patches mensalmente com o cronograma da MS é adequada para um cluster de produção do Windows?
Sim, no entanto, um cluster não deve ter nenhum tempo de inatividade associado a um patch, pois deve fazer failover dos trabalhos para outro nó - eu NÃO corrigiria o cluster inteiro ao mesmo tempo (isso seria uma loucura)
2. Existem ganchos de software no WSUS onde poderíamos dizer "por favor, não reinicie ainda"?
Não há como os usuários finais interromperem uma atualização ou reinicialização do WSUS, mas me parece que você tem um problema real de comunicação entre seu grupo e o grupo de TI; no entanto, você poderá perder um nó por vez, com pouco impacto na produção.
Responder2
Ao usar o Config Mgr para gerenciar a implantação de atualizações, você pode impedir a reinicialização dos servidores. Portanto, as atualizações são aplicadas (mas podem não entrar em vigor até a reinicialização) e a TI terá relatórios mostrando os servidores que estão aguardando uma reinicialização. Eles podem facilmente fornecer essa lista e espero que você possa agendar facilmente as reinicializações de nós específicos sem muita interrupção. A TI pode facilmente ter uma implantação à prova de falhas (com reinicializações forçadas) e também um longo prazo, de modo que isso acabará forçando as atualizações e reinicializações caso você não cumpra sua parte do acordo!
Para as implantações de atualização padrão, a TI (e você) provavelmente desejará prazos muito curtos para implantação totalmente silenciosa (implantação sem reinicialização) e também uma implantação com prazo um pouco mais longo que não seja silenciosa, para que você receba uma notificação se fizer login no servidor. Nenhuma dessas implantações deve forçar a reinicialização.
Você ainda pode se deparar com a situação em que algo falha porque uma biblioteca ou outro componente de código foi atualizado enquanto não estava em uso e, em seguida, é usado antes que a reinicialização faça com que o restante das atualizações entre em vigor.
Esta é uma maneira eficiente de conseguir o que você e a TI desejam e cada um de vocês tem alguma visibilidade do que está acontecendo. O relatório de quais servidores estão em que estado, de acordo com as implantações, também é realmente útil para vocês dois.
Responder3
Parece que você está recebendo muita atitude de 'falar com a mão' do seu departamento de TI. Você precisa sentá-los (ou suborná-los com cerveja?) Explicar sua situação e ver se eles podem fazer algo como criar um servidor WSUS downstream com aprovações manuais de patches.
As configurações do WSUS são todas definidas por Políticas de Grupo, definidas no Active Directory no nível do domínio ou da UO. Se os servidores estiverem no domínio corporativo sem uma UO separada, eles obterão o que todo mundo está obtendo, o que não parece apropriado.
Se você não conseguir resolver o problema com seu departamento de TI, remova os computadores do domínio?