Atualizar e atualizar clusters do Azure Service Fabric

Um cluster do Azure Service Fabric é um recurso do qual é proprietário, mas é parcialmente gerido pela Microsoft. Este artigo descreve as opções para quando e como atualizar o cluster do Azure Service Fabric.

Atualizações automáticas versus manuais

É fundamental garantir que o cluster do Service Fabric está sempre a executar uma versão de runtime suportada. Sempre que a Microsoft anunciar o lançamento de uma nova versão do Service Fabric, a versão anterior é marcada para fim do suporte após um mínimo de 60 dias a partir dessa data. São anunciadas novas versões no blogue da equipa do Service Fabric.

Catorze dias antes da expiração da versão em que o cluster está em execução, é gerado um evento de estado de funcionamento que coloca o cluster num estado de funcionamento de Aviso . O cluster permanece num estado de aviso até atualizar para uma versão de runtime suportada.

Pode definir o cluster para receber atualizações automáticas do Service Fabric à medida que são lançadas pela Microsoft ou pode escolher manualmente a partir de uma lista de versões atualmente suportadas. Estas opções estão disponíveis na secção Atualizações de recursos de infraestrutura do recurso de cluster do Service Fabric.

Selecione Atualizações automáticas ou manuais na secção

Também pode definir o modo de atualização do cluster e selecionar uma versão de runtime com um modelo de Resource Manager.

As atualizações automáticas são o modo de atualização recomendado, uma vez que esta opção garante que o cluster permanece num estado suportado e beneficia das correções e funcionalidades mais recentes, ao mesmo tempo que lhe permite agendar atualizações de uma forma menos disruptiva para as suas cargas de trabalho através de uma estratégia de implementação de ondas .

Nota

Se alterar um cluster existente para o modo automático, o cluster será inscrito para o próximo período de atualização a partir de uma nova versão. São anunciadas novas versões no blogue da equipa do Service Fabric. Por período de atualização, é escolhido o caminho de atualização mais elevado possível. Veja versões suportadas. O modo de atualização manual aciona uma atualização imediata.

Implementação faseada para atualizações automáticas

Com a implementação de ondas, pode minimizar a interrupção de uma atualização para o cluster ao selecionar o nível de maturidade de uma atualização, dependendo da carga de trabalho. Por exemplo, pode configurar um pipeline de implementação de fase de teste> -fase ->produção para os vários clusters do Service Fabric para testar a compatibilidade de uma atualização do runtime antes de o aplicar às cargas de trabalho de produção.

Para optar ativamente por ativar a implementação, especifique um dos seguintes valores de onda para o cluster (no modelo de implementação):

  • Wave 0: os clusters são atualizados assim que é lançada uma nova compilação do Service Fabric. Destina-se a clusters de teste/desenvolvimento.
  • Wave 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é-prod/teste.
  • Wave 2: os clusters são atualizados duas semanas (14 dias) após o lançamento de uma nova compilação. Destina-se a clusters de produção.

Pode registar-se para receber notificações por e-mail com ligações para obter mais ajuda se uma atualização do cluster falhar. Veja Implementação wave para obter atualizações automáticas para começar.

Fases da atualização automática

A Microsoft mantém o código e a configuração do runtime do Service Fabric que é executado num cluster do Azure. Executamos atualizações monitorizadas automaticamente para o software conforme necessário. Estas atualizações podem ser código, configuração ou ambos. Para minimizar o impacto destas atualizações nas suas aplicações, estas são executadas nas seguintes fases:

Fase 1: é efetuada uma atualização com todas as políticas de estado de funcionamento do cluster

Durante esta fase, as atualizações prosseguem um domínio de atualização de cada vez e as aplicações que estavam em execução no cluster continuam a ser executadas sem qualquer período de indisponibilidade. As políticas de estado de funcionamento do cluster (para o estado de funcionamento do nó e o estado de funcionamento da aplicação) são cumpridas durante a atualização.

Se as políticas de estado de funcionamento do cluster não forem cumpridas, a atualização é revertida e é enviado um e-mail para o proprietário da subscrição. O e-mail contém as seguintes informações:

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

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

Se as políticas de estado de funcionamento do cluster forem cumpridas, a atualização será considerada com êxito e marcada como concluída. Esta situação pode ocorrer durante a atualização inicial ou qualquer uma das execuções de atualização nesta fase. Não existe confirmação por e-mail de uma execução com êxito, 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 do cluster tenha êxito sem afetar a disponibilidade da aplicação.

Fase 2: é efetuada uma atualização apenas com políticas de estado de funcionamento predefinidas

As políticas de estado de funcionamento nesta fase são definidas de forma a que o número de aplicações em bom estado de funcionamento no início da atualização permaneça igual durante o processo de atualização. Tal como na Fase 1, as atualizações da Fase 2 prosseguem um domínio de atualização de cada vez e as aplicações em execução no cluster continuam a ser executadas sem qualquer período de indisponibilidade. As políticas de estado de funcionamento do cluster (uma combinação do estado de funcionamento do nó e do estado de funcionamento de todas as aplicações em execução no cluster) são cumpridas durante a atualização.

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

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

Tentamos executar a mesma atualização mais algumas vezes caso as atualizações falhem por motivos de infraestrutura. É enviado um e-mail de lembrete alguns dias antes do fim de n dias. Após os n dias a contar da data em que o e-mail foi enviado, avançamos para a Fase 3. Os e-mails que lhe enviamos na Fase 2 têm de ser levados a sério e as ações de remediação têm de ser tomadas.

Se as políticas de estado de funcionamento do cluster forem cumpridas, a atualização será considerada com êxito e marcada como concluída. Isto pode acontecer durante a atualização inicial ou qualquer uma das execuções de atualização nesta fase. Não existe confirmação por e-mail de uma execução bem-sucedida.

Fase 3: é efetuada uma atualização através de políticas de saúde agressivas

Estas políticas de estado de funcionamento nesta fase estão orientadas para a conclusão da atualização em vez do estado de funcionamento das aplicações. Algumas atualizações de cluster acabam nesta fase. Se o cluster chegar a esta fase, existe uma boa hipótese de a sua aplicação ficar em mau estado de funcionamento e/ou perder a disponibilidade.

À semelhança das outras duas fases, as atualizações da Fase 3 prosseguem um domínio de atualização de cada vez.

Se as políticas de estado de funcionamento do cluster não forem cumpridas, a atualização será revertida. Tentamos executar a mesma atualização mais algumas vezes caso as atualizações falhem por motivos de infraestrutura. Depois disso, o cluster é afixado, para que deixe de receber suporte e/ou atualizações.

Um e-mail com estas informações é enviado ao proprietário da subscrição, juntamente com as ações de remediação. Não esperamos que nenhum cluster entre num estado em que a Fase 3 falhou.

Se as políticas de estado de funcionamento do cluster forem cumpridas, a atualização será considerada com êxito e marcada como concluída. Isto pode acontecer durante a atualização inicial ou qualquer uma das execuções de atualização nesta fase. Não existe confirmação por e-mail de uma execução bem-sucedida.

Políticas personalizadas para atualizações manuais

Pode especificar políticas personalizadas para atualizações manuais do cluster. Estas políticas são aplicadas sempre que seleciona uma nova versão de runtime, o que aciona o sistema para iniciar a atualização do cluster. Se não substituir as políticas, são utilizadas as predefinições. Para obter mais informações, consulte Definir políticas personalizadas para atualizações manuais.

Outras atualizações do cluster

Fora da atualização do runtime, existem várias outras ações que poderá ter de efetuar para manter o cluster atualizado, incluindo o seguinte:

Gerir certificados

O Service Fabric utiliza certificados de servidor X.509 que especifica quando cria um cluster para proteger as comunicações entre nós de cluster e autenticar clientes. Pode adicionar, atualizar ou eliminar certificados para o cluster e o cliente no portal do Azure ou com a CLI do PowerShell/Azure. Para saber mais, leia Adicionar ou remover certificados

Abrir portas da aplicação

Pode alterar as portas da aplicação ao alterar as propriedades do recurso Balanceador de Carga que estão associadas ao tipo de nó. Pode utilizar a portal do Azure ou pode utilizar o PowerShell/CLI do Azure. Para obter mais informações, leia Abrir portas de aplicação para um cluster.

Definir propriedades do nó

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

Para obter detalhes sobre a utilização de restrições de colocação, propriedades de nós e como defini-las, leia as propriedades do nó e as restrições de colocação.

Adicionar métricas de capacidade

Para cada um dos tipos de nó, pode adicionar métricas de capacidade personalizadas que pretende utilizar nas suas aplicações para comunicar a carga. Para obter detalhes sobre a utilização de métricas de capacidade para comunicar a carga, veja o Cluster do Service Fabric Resource Manager Documentos sobre Descrever o Cluster, as Métricas e a Carga.

Personalizar definições para o cluster

Muitas definições de configuração diferentes podem ser personalizadas num cluster, como o nível de fiabilidade das propriedades do cluster e do nó. Para obter mais informações, leia Definições dos recursos de infraestrutura do cluster do Service Fabric.

Atualizar imagens do SO para nós de cluster

A ativação de atualizações automáticas de imagens do SO para os nós de cluster do Service Fabric é uma melhor prática. Para tal, existem vários requisitos de cluster e passos a seguir. Outra opção é utilizar a Aplicação de Orquestração de Patches (POA), uma aplicação do Service Fabric que automatiza a aplicação de patches do sistema operativo num cluster do Service Fabric sem tempo de inatividade. Para saber mais sobre estas opções, veja Patch the Windows operating system in your Service Fabric cluster (Corrigir o sistema operativo Windows no cluster do Service Fabric).

Passos seguintes