Atualizar os clusters do Azure Service Fabric

Um cluster do Azure Service Fabric é um recurso que você possui, mas é parcialmente gerenciado pela Microsoft. Este artigo descreve as opções para quando e como atualizar seu cluster do Azure Service Fabric.

Atualizações automáticas versus manuais

É fundamental garantir que seu cluster do Service Fabric esteja sempre executando uma versão de tempo de execução suportada. Cada vez que a Microsoft anuncia o lançamento de uma nova versão do Service Fabric, a versão anterior é marcada para o fim do suporte após um mínimo de 60 dias a partir dessa data. Novos lançamentos são anunciados no blog da equipe do Service Fabric.

Quatorze dias antes da expiração da versão em execução do cluster, é gerado um evento de integridade que coloca o cluster em um estado de integridade de Aviso . O cluster permanece em um estado de aviso até que você atualize para uma versão de tempo de execução suportada.

Você pode configurar seu cluster para receber atualizações automáticas do Service Fabric à medida que são lançadas pela Microsoft ou pode escolher manualmente em uma lista de versões atualmente suportadas. Essas opções estão disponíveis na seção Atualizações de malha do recurso de cluster do Service Fabric.

Você também pode definir o modo de atualização do cluster e selecionar uma versão de tempo de execução usando um modelo do Gerenciador de Recursos.

As atualizações automáticas são o modo de atualização recomendado, pois essa opção garante que seu cluster permaneça em um estado suportado e se beneficie das correções e recursos mais recentes, ao mesmo tempo em que permite agendar atualizações de uma maneira que seja menos perturbadora para suas cargas de trabalho usando uma estratégia de implantação de onda.

Implantação do Wave para atualizações automáticas

Com a implantação do wave, você pode minimizar a interrupção de uma atualização para seu cluster selecionando o nível de maturidade de uma atualização, dependendo da sua carga de trabalho. Por exemplo, você pode configurar um pipeline de implantação de onda Test ->Stage ->Production para seus vários clusters do Service Fabric para testar a compatibilidade de uma atualização de tempo de execução antes de aplicá-la às suas cargas de trabalho de produção.

Para aceitar a implantação de onda, especifique um dos seguintes valores de onda para seu cluster (em seu modelo de implantação):

• Onda 0: Os clusters são atualizados assim que uma nova compilação do Service Fabric é lançada. Destinado a clusters de teste/desenvolvimento.
• Onda 1: Os clusters são atualizados uma semana (sete dias) após o lançamento de uma nova compilação. Destina-se a clusters de pré-produção/preparação.
• Onda 2: Os clusters são atualizados duas semanas (14 dias) após o lançamento de uma nova compilação. Destinado a clusters de produção.

Você pode se registrar para receber notificações por e-mail com links para ajudar ainda mais se uma atualização de cluster falhar. Consulte Implantação do Wave para atualizações automáticas para começar.

Fases da atualização automática

A Microsoft mantém o código de tempo de execução e a configuração do Service Fabric que são executados em um cluster do Azure. Realizamos atualizações monitoradas automaticamente para o software conforme necessário. Essas atualizações podem ser código, configuração ou ambas. Para minimizar o impacto dessas atualizações em seus aplicativos, elas são executadas nas seguintes fases:

Fase 1: Uma atualização é executada usando todas as diretivas de integridade do cluster

Durante essa fase, as atualizações prosseguem um domínio de atualização de cada vez, e os aplicativos que estavam sendo executados no cluster continuam a ser executados sem qualquer tempo de inatividade. As políticas de integridade do cluster (para integridade do nó e integridade do aplicativo) são respeitadas durante a atualização.

Se as políticas de integridade do cluster não forem atendidas, a atualização será revertida e um e-mail será enviado ao proprietário da assinatura. O e-mail contém as seguintes informações:

• Notificação de que tivemos que reverter uma atualização de cluster.
• Ações corretivas sugeridas, se houver.
• O número de dias (n) até executarmos a Fase 2.

Tentamos executar a mesma atualização mais algumas vezes, caso alguma atualização falhe por motivos de infraestrutura. Após os n dias a partir da data em que o e-mail foi enviado, continuamos para a Fase 2.

Se as políticas de integridade do cluster forem atendidas, a atualização será considerada bem-sucedida e marcada como concluída. Essa situação pode acontecer durante a atualização inicial ou qualquer uma das reexecuções de atualização nesta fase. Não há confirmação por e-mail de uma execução bem-sucedida, para evitar o envio excessivo de e-mails. Receber um e-mail indica uma exceção às operações normais. Esperamos que a maioria das atualizações de cluster seja bem-sucedida sem afetar a disponibilidade do seu aplicativo.

Fase 2: Uma atualização é executada usando somente as políticas de integridade padrão

As políticas de integridade nesta fase são definidas de tal forma que o número de aplicativos que estavam íntegros no início da atualização permanece o mesmo durante o processo de atualização. Como na Fase 1, as atualizações da Fase 2 prosseguem um domínio de atualização de cada vez, e os aplicativos que estavam sendo executados no cluster continuam a ser executados sem qualquer tempo de inatividade. As diretivas de integridade do cluster (uma combinação da integridade do nó e da integridade de todos os aplicativos em execução no cluster) são respeitadas durante a atualização.

Se as políticas de integridade do cluster em vigor não forem atendidas, a atualização será revertida. Em seguida, um e-mail é enviado para o proprietário da assinatura. O e-mail contém as seguintes informações:

• Notificação de que tivemos que reverter uma atualização de cluster.
• Ações corretivas sugeridas, se houver.
• O número de dias (n) até executarmos a Fase 3.

Tentamos executar a mesma atualização mais algumas vezes, caso alguma atualização falhe por motivos de infraestrutura. Um e-mail de lembrete é enviado alguns dias antes de n dias acabarem. Após os n dias a partir da data em que o e-mail foi enviado, passamos para a Fase 3. Os e-mails que lhe enviamos na Fase 2 devem ser levados a sério e medidas corretivas devem ser tomadas.

Se as políticas de integridade do cluster forem atendidas, a atualização será considerada bem-sucedida e marcada como concluída. Isso pode acontecer durante a atualização inicial ou qualquer uma das reexecuções de atualização nesta fase. Não há confirmação por e-mail de uma execução bem-sucedida.

Fase 3: Uma atualização é executada usando políticas de integridade agressivas

Essas políticas de integridade nesta fase são voltadas para a conclusão da atualização e não para a integridade dos aplicativos. Poucas atualizações de cluster acabam nessa fase. Se o cluster chegar a essa fase, há uma boa chance de que seu aplicativo não esteja íntegro e/ou perca disponibilidade.

Semelhante às outras duas fases, as atualizações da Fase 3 prosseguem um domínio de atualização de cada vez.

Se as diretivas de integridade do cluster não forem atendidas, a atualização será revertida. Tentamos executar a mesma atualização mais algumas vezes, caso alguma atualização falhe por motivos de infraestrutura. Depois disso, o cluster é fixado, para que não receba mais suporte e/ou atualizações.

Um e-mail com essas informações é enviado ao proprietário da assinatura, juntamente com as ações corretivas. Não esperamos que nenhum cluster entre em um estado em que a Fase 3 tenha falhado.

Se as políticas de integridade do cluster forem atendidas, a atualização será considerada bem-sucedida e marcada como concluída. Isso pode acontecer durante a atualização inicial ou qualquer uma das reexecuções de atualização nesta fase. Não há confirmação por e-mail de uma execução bem-sucedida.

Políticas personalizadas para atualizações manuais

Você pode especificar políticas personalizadas para atualizações manuais de cluster. Essas políticas são aplicadas sempre que você seleciona uma nova versão de tempo de execução, o que aciona o sistema para iniciar a atualização do cluster. Se você não substituir as políticas, os padrões serão usados. Para saber mais, consulte Definir políticas personalizadas para atualizações manuais.

Outras atualizações de cluster

Além da atualização do tempo de execução, há várias outras ações que você pode precisar executar para manter o cluster atualizado, incluindo o seguinte:

Gerenciando certificados

O Service Fabric usa certificados de servidor X.509 que você especifica ao criar um cluster para proteger as comunicações entre nós de cluster e autenticar clientes. Você pode adicionar, atualizar ou excluir certificados para o cluster e o cliente no portal do Azure ou usando o PowerShell/CLI do Azure. Para saber mais, leia Adicionar ou remover certificados

Abrindo portas de aplicativo

Você pode alterar as portas do aplicativo alterando as propriedades do recurso do Balanceador de Carga associadas ao tipo de nó. Você pode usar o portal do Azure ou a CLI do PowerShell/Azure. Para obter mais informações, leia Abrir portas de aplicativo para um cluster.

Definindo propriedades do nó

Às vezes, você pode querer garantir que determinadas cargas de trabalho sejam executadas apenas em determinados tipos de nós no cluster. Por exemplo, algumas cargas de trabalho podem exigir GPUs ou SSDs, enquanto outras não. Para cada um dos tipos de nó em um cluster, você pode adicionar propriedades de nó personalizadas aos nós do cluster. As restrições de posicionamento são as instruções anexadas a serviços individuais que selecionam uma ou mais propriedades de nó. As restrições de posicionamento definem onde os serviços devem ser executados.

Para obter detalhes sobre o uso de restrições de posicionamento, propriedades de nó e como defini-las, leia propriedades de nó e restrições de posicionamento.

Adicionando métricas de capacidade

Para cada um dos tipos de nó, você pode adicionar métricas de capacidade personalizadas que deseja usar em seus aplicativos para relatar a carga. Para obter detalhes sobre o uso de métricas de capacidade para relatar a carga, consulte os documentos do Service Fabric Cluster Resource Manager em Descrição do cluster e métricas e carga.

Personalizando configurações para seu cluster

Muitas definições de configuração diferentes podem ser personalizadas em um cluster, como o nível de confiabilidade do cluster e das propriedades do nó. Para obter mais informações, leia Configurações de malha de cluster do Service Fabric.

Atualizando imagens do sistema operacional para nós de cluster

Habilitar atualizações automáticas de imagens do sistema operacional para os nós de cluster do Service Fabric é uma prática recomendada. Para fazer isso, há vários requisitos de cluster e etapas a serem tomadas. Outra opção é usar o Patch Orchestration Application (POA), um aplicativo do Service Fabric que automatiza a aplicação de patches do sistema operacional em um cluster do Service Fabric sem tempo de inatividade. Para saber mais sobre essas opções, consulte Corrigir o sistema operacional Windows no cluster do Service Fabric.

Próximos passos

• Gerenciar atualizações do Service Fabric
• Personalizar as configurações de cluster do Service Fabric
• Dimensionar o cluster para dentro e para fora
• Saiba mais sobre atualizações de aplicativos