Compartilhar via


Configurar o agendamento de aplicação de patch no SO para clusters HDInsight baseados em Linux

Importante

As imagens do Ubuntu ficam disponíveis para a criação do novo cluster do Azure HDInsight dentro de 3 meses após ser publicado. Os clusters em execução não são corrigidos automaticamente. Os clientes devem usar ações de script ou outros mecanismos para aplicar o patch de um cluster em execução. Como prática recomendada, você pode executar essas ações de script e aplicar atualizações de segurança logo após a criação do cluster.

O HDInsight fornece suporte para que você execute tarefas comuns no cluster, como instalação de patches do SO, atualizações de segurança de SO e reinicialização de nós. Essas tarefas são realizadas usando os dois scripts a seguir que podem ser executados como ações de script e configurados com parâmetros:

  • schedule-reboots.sh - Fazer uma reinicialização imediata ou agendar uma reinicialização nos nós de cluster.
  • install-updates-schedule-reboots.sh - Instalar todas as atualizações, apenas as atualizações de kernel + segurança ou apenas as atualizações de kernel.

Observação

As ações de script não aplicarão automaticamente atualizações para todos os ciclos de atualização futuros. Execute os scripts todas as vezes que novas atualizações precisarem ser aplicadas para instalar as atualizações e reinicie a VM.

Se você estiver usando um firewall para restrição de rede, a URL abaixo precisará estar na lista de permissões.

Preparação

Aplique um patch em um ambiente de não produção representativo antes da implantação na produção. Desenvolva um plano para testar adequadamente seu sistema antes de aplicar o patch real.

De tempos em tempos, a partir de uma sessão SSH com o cluster, você pode receber uma mensagem informando que atualizações de segurança estão disponíveis. A mensagem pode ser semelhante a:

89 packages can be updated.
82 updates are security updates.

*** System restart required ***

Welcome to Spark on HDInsight.

A aplicação de patch é opcional e fica a seu critério.

Reiniciar nós

O script schedule-reboots define o tipo de reinicialização que será executada nas máquinas no cluster. Ao enviar a ação de script, defina-a para aplicar em todos os três tipos de nó: head node, nó de trabalho e zookeeper. Se o script não for aplicado a um tipo de nó, as VMs desse tipo de nó não serão atualizadas ou reiniciadas.

O schedule-reboots script aceita um parâmetro numérico:

Parâmetro Valores aceitos Definição
Tipo de reinicialização a executar 1 ou 2 Um valor de 1 habilita a reinicialização do agendamento (agendado em 12-24 horas). Um valor de 2 habilita a reinicialização imediata (em 5 minutos). Se nenhum parâmetro for especificado, o padrão será 1.

Instalar atualizações e reiniciar nós

O script install-updates-schedule-reboots.sh fornece opções para instalar diferentes tipos de atualizações e reiniciar a VM.

O script install-updates-schedule-reboots aceita dois parâmetros numéricos, conforme descrito na tabela a seguir:

Parâmetro Valores aceitos Definição
Tipo de atualizações a instalar 0, 1 ou 2 Um valor de 0 instala apenas atualizações de kernel. Um valor de 1 instala o kernel + atualizações de segurança e 2 instala todas as atualizações. Se nenhum parâmetro for especificado, o padrão será 0.
Tipo de reinicialização a executar 0, 1 ou 2 Um valor de 0 desabilita a reinicialização. Um valor de 1 habilita a reinicialização do agendamento e 2 habilita a reinicialização imediata. Se nenhum parâmetro for especificado, o padrão será 0. O usuário deve alterar o parâmetro de entrada 1 para o parâmetro de entrada 2.

Observação

Você deve marcar um script como persistente após aplicá-lo a um cluster existente. Caso contrário, quaisquer nós novos criado por meio de operações de dimensionamento usarão o agendamento de aplicação de patch padrão. Se você aplicar o script como parte do processo de criação de cluster, ele será persistido automaticamente.

Observação

A opção Reinicialização Agendada faz uma reinicialização sem-interrupção automatizada dos nós de cluster com patch em um período de 12 a 24 horas e leva em conta a alta disponibilidade, o domínio de atualização e as considerações de domínio de falha. A Reinicialização Agendada não encerra as cargas de trabalho em execução, mas pode eliminar a capacidade do cluster enquanto os nós não estão disponíveis, levando a tempos de processamento mais longos.

Próximas etapas

Para conhecer as etapas específicas sobre como usar a ação de script, confira as seções a seguir em Personalizar clusters HDInsight baseados em Linux usando a ação de script: