Atualização da aplicação do Service Fabric: Tópicos avançados

  • Artigo

Adicionar ou remover tipos de serviço durante uma atualização da aplicação

Se for adicionado um novo tipo de serviço a uma aplicação publicada como parte de uma atualização, o novo tipo de serviço é adicionado à aplicação implementada. Esta atualização não afeta nenhuma das instâncias de serviço que já faziam parte da aplicação, mas tem de ser criada uma instância do tipo de serviço que foi adicionada para que o novo tipo de serviço esteja ativo (veja New-ServiceFabricService).

Da mesma forma, os tipos de serviço podem ser removidos de uma aplicação como parte de uma atualização. No entanto, todas as instâncias de serviço do tipo de serviço a remover têm de ser removidas antes de prosseguir com a atualização (veja Remove-ServiceFabricService).

Evitar falhas de ligação durante o período de indisponibilidade planeado do serviço sem estado

Para os tempos de inatividade de instâncias sem estado planeados, como a atualização da aplicação/cluster ou a desativação do nó, as ligações podem ser removidas à medida que o ponto final exposto é removido após a instância ficar inativa, o que resulta em encerramentos de ligação forçados.

Para evitar esta situação, configure a funcionalidade RequestDrain ao adicionar uma duração de atraso de fecho da instância na configuração do serviço para permitir que os pedidos existentes a partir do cluster se esgotem nos pontos finais expostos. Isto é conseguido porque o ponto final anunciado pela instância sem estado é removido antes de o atraso começar antes de fechar a instância. Este atraso permite que os pedidos existentes escorram corretamente antes que a instância realmente caia. Os clientes são notificados da alteração do ponto final por uma função de chamada de retorno no momento do início do atraso, para que possam resolver novamente o ponto final e evitar enviar novos pedidos para a instância que está a ficar inativa. Estes pedidos podem ter origem nos clientes que utilizam o Proxy Inverso ou a utilização de API de resolução de pontos finais de serviço com o modelo de notificação (ServiceNotificationFilterDescription) para atualizar os pontos finais.

Configuração do serviço

Existem várias formas de configurar o atraso no lado do serviço.

  • Ao criar um novo serviço, especifique um -InstanceCloseDelayDuration:

    New-ServiceFabricService -Stateless [-ServiceName] <Uri> -InstanceCloseDelayDuration <TimeSpan>

  • Ao definir o serviço na secção de predefinições no manifesto da aplicação, atribua a InstanceCloseDelayDurationSeconds propriedade :

          <StatelessService ServiceTypeName="Web1Type" InstanceCount="[Web1_InstanceCount]" InstanceCloseDelayDurationSeconds="15">
          <SingletonPartition />
      </StatelessService>

  • Ao atualizar um serviço existente, especifique um -InstanceCloseDelayDuration:

    Update-ServiceFabricService [-Stateless] [-ServiceName] <Uri> [-InstanceCloseDelayDuration <TimeSpan>]`

  • Ao criar ou atualizar um serviço existente através do modelo do ARM, especifique o InstanceCloseDelayDuration valor (versão mínima da API suportada: 2020-03-01):

    {
  "apiVersion": "2020-03-01",
  "type": "Microsoft.ServiceFabric/clusters/applications/services",
  "name": "[concat(parameters('clusterName'), '/', parameters('applicationName'), '/', parameters('serviceName'))]",
  "location": "[variables('clusterLocation')]",
  "dependsOn": [
    "[concat('Microsoft.ServiceFabric/clusters/', parameters('clusterName'), '/applications/', parameters('applicationName'))]"
  ],
  "properties": {
    "provisioningState": "Default",
    "serviceKind": "Stateless",
    "serviceTypeName": "[parameters('serviceTypeName')]",
    "instanceCount": "-1",
    "partitionDescription": {
      "partitionScheme": "Singleton"
    },
    "serviceLoadMetrics": [],
    "servicePlacementPolicies": [],
    "defaultMoveCost": "",
    "instanceCloseDelayDuration": "00:00:30.0"
  }
}

Configuração do cliente

Para receber uma notificação quando um ponto final for alterado, os clientes devem registar uma chamada de retorno. Veja Sample ServiceNotificationFilterDescription. A notificação de alteração é uma indicação de que os pontos finais foram alterados, que o cliente deve resolver novamente os pontos finais e não utilizar os pontos finais que já não são anunciados, uma vez que ficarão inativos em breve.

Substituições de atualização opcionais

Além de definir durações de atraso predefinidas por serviço, também pode substituir o atraso durante a atualização da aplicação/cluster com a mesma opção (InstanceCloseDelayDurationSec):

Start-ServiceFabricApplicationUpgrade [-ApplicationName] <Uri> [-ApplicationTypeVersion] <String> [-InstanceCloseDelayDurationSec <UInt32>]

Start-ServiceFabricClusterUpgrade [-CodePackageVersion] <String> [-ClusterManifestVersion] <String> [-InstanceCloseDelayDurationSec <UInt32>]

A duração do atraso substituída aplica-se apenas à instância de atualização invocada e, de outra forma, não altera as configurações individuais de atraso do serviço. Por exemplo, pode utilizá-lo para especificar um atraso de 0 para ignorar quaisquer atrasos de atualização pré-configurados.

Nota

  • As definições para drenar pedidos não conseguirão impedir que o Balanceador de Carga do Azure envie novos pedidos para os pontos finais que estão a ser drenados.
  • Um mecanismo de resolução baseado em reclamações não resultará na drenagem correta dos pedidos, uma vez que aciona uma resolução do serviço após uma falha. Conforme descrito anteriormente, deve ser melhorado para subscrever as notificações de alteração de ponto final com ServiceNotificationFilterDescription.
  • As definições não são honradas quando a atualização é uma definição sem impacto, ou seja, quando as réplicas não serão desativadas durante a atualização.
  • O valor máximo de InstanceCloseDelayDuration que pode ser configurado na descrição do serviço ou instanceCloseDelayDurationSec na descrição da atualização não pode ser maior do que a configuração do cluster FailoverManager.MaxInstanceCloseDelayDurationInSeconds, que é predefinida para 1800 segundos. Para atualizar o valor máximo, a configuração ao nível do cluster deve ser atualizada. Esta configuração só está disponível na versão de runtime 9.0 ou posterior.

Nota

Esta funcionalidade pode ser configurada em serviços existentes com Update-ServiceFabricService cmdlet ou o modelo do ARM, conforme mencionado acima, quando a versão do código do cluster é 7.1.XXX ou superior.

Modo de atualização manual

Nota

O modo de atualização Monitorizado é recomendado para todas as atualizações do Service Fabric. O modo de atualização UnmonitoredManual só deve ser considerado para atualizações falhadas ou suspensas.

No modo Monitorizado , o Service Fabric aplica políticas de estado de funcionamento para garantir que a aplicação está em bom estado de funcionamento à medida que a atualização progride. Se as políticas de estado de funcionamento forem violadas, a atualização será suspensa ou revertida automaticamente, dependendo da FailureAction especificada.

No modo UnmonitoredManual , o administrador da aplicação tem controlo total sobre a progressão da atualização. Este modo é útil ao aplicar políticas de avaliação de estado de funcionamento personalizadas ou efetuar atualizações não convencionais para ignorar completamente a monitorização do estado de funcionamento (por exemplo, a aplicação já está em perda de dados). Uma atualização em execução neste modo irá suspender-se depois de concluir cada UD e tem de ser explicitamente retomada com Resume-ServiceFabricApplicationUpgrade. Quando uma atualização é suspensa e está pronta para ser retomada pelo utilizador, o estado de atualização mostrará RollforwardPending (consulte UpgradeState).

Por fim, o modo UnmonitoredAuto é útil para realizar iterações de atualização rápida durante o desenvolvimento ou teste do serviço, uma vez que não é necessária nenhuma entrada do utilizador e não são avaliadas políticas de estado de funcionamento da aplicação.

Atualizar com um pacote de diferença

Em vez de aprovisionar um pacote de aplicação completo, as atualizações também podem ser efetuadas através do aprovisionamento de pacotes difusos que contêm apenas os pacotes de código/configuração/dados atualizados, juntamente com o manifesto completo da aplicação e manifestos de serviço completos. Os pacotes de aplicações completos só são necessários para a instalação inicial de uma aplicação no cluster. As atualizações subsequentes podem ser provenientes de pacotes de aplicações completos ou pacotes difusos.

Qualquer referência no manifesto da aplicação ou nos manifestos de serviço de um pacote difuso que não possa ser encontrado no pacote de aplicação é substituída automaticamente pela versão atualmente aprovisionada.

Os cenários para utilizar um pacote de diferença são:

  • Quando tem um pacote de aplicações grande que referencia vários ficheiros de manifesto de serviço e/ou vários pacotes de código, pacotes de configuração ou pacotes de dados.
  • Quando tiver um sistema de implementação que gere o esquema de compilação diretamente a partir do processo de compilação da aplicação. Neste caso, apesar de o código não ter sido alterado, as assemblagens recém-criadas recebem uma soma de verificação diferente. A utilização de um pacote de aplicação completo exigiria que atualizasse a versão em todos os pacotes de código. Com um pacote difuso, só fornece os ficheiros que foram alterados e os ficheiros de manifesto onde a versão foi alterada.

Quando uma aplicação é atualizada com o Visual Studio, é publicado automaticamente um pacote de diferenças. Para criar manualmente um pacote de diferenças, o manifesto da aplicação e os manifestos de serviço têm de ser atualizados, mas apenas os pacotes alterados devem ser incluídos no pacote de aplicação final.

Por exemplo, vamos começar com a seguinte aplicação (números de versão fornecidos para facilitar a compreensão):

app1           1.0.0
  service1     1.0.0
    code       1.0.0
    config     1.0.0
  service2     1.0.0
    code       1.0.0
    config     1.0.0

Vamos supor que queria atualizar apenas o pacote de código do service1 com um pacote de diferenças. A aplicação atualizada tem as seguintes alterações de versão:

app1           2.0.0      <-- new version
  service1     2.0.0      <-- new version
    code       2.0.0      <-- new version
    config     1.0.0
  service2     1.0.0
    code       1.0.0
    config     1.0.0

Neste caso, atualize o manifesto da aplicação para 2.0.0 e o manifesto de serviço do service1 para refletir a atualização do pacote de código. A pasta do pacote de aplicações teria a seguinte estrutura:

app1/
  service1/
    code/

Por outras palavras, crie um pacote de aplicação completo normalmente e, em seguida, remova quaisquer pastas de código/configuração/pacote de dados para as quais a versão não tenha sido alterada.

Atualizar os parâmetros da aplicação independentemente da versão

Por vezes, é desejável alterar os parâmetros de uma aplicação do Service Fabric sem alterar a versão do manifesto. Isto pode ser feito convenientemente com o sinalizador -ApplicationParameter com o cmdlet Start-ServiceFabricApplicationUpgrade do PowerShell do Azure Service Fabric. Assuma uma aplicação do Service Fabric com as seguintes propriedades:

PS C:\> Get-ServiceFabricApplication -ApplicationName fabric:/Application1

ApplicationName        : fabric:/Application1
ApplicationTypeName    : Application1Type
ApplicationTypeVersion : 1.0.0
ApplicationStatus      : Ready
HealthState            : Ok
ApplicationParameters  : { "ImportantParameter" = "1"; "NewParameter" = "testBefore" }

Agora, atualize a aplicação com o cmdlet Start-ServiceFabricApplicationUpgrade . Este exemplo mostra uma atualização monitorizada, mas também pode ser utilizada uma atualização não monitorizada. Para ver uma descrição completa dos sinalizadores aceites por este cmdlet, veja a referência do módulo do PowerShell do Azure Service Fabric

PS C:\> $appParams = @{ "ImportantParameter" = "2"; "NewParameter" = "testAfter"}

PS C:\> Start-ServiceFabricApplicationUpgrade -ApplicationName fabric:/Application1 -ApplicationTypeVers
ion 1.0.0 -ApplicationParameter $appParams -Monitored

Após a atualização, confirme que a aplicação tem os parâmetros atualizados e a mesma versão:

PS C:\> Get-ServiceFabricApplication -ApplicationName fabric:/Application1

ApplicationName        : fabric:/Application1
ApplicationTypeName    : Application1Type
ApplicationTypeVersion : 1.0.0
ApplicationStatus      : Ready
HealthState            : Ok
ApplicationParameters  : { "ImportantParameter" = "2"; "NewParameter" = "testAfter" }

Reverter atualizações de aplicações

Embora as atualizações possam ser revertidas num de três modos (Monitorizado, UnmonitoredAuto ou UnmonitoredManual), só podem ser revertidos no modo UnmonitoredAuto ou UnmonitoredManual . Reverter no modo UnmonitoredAuto funciona da mesma forma que avançar com a exceção de que o valor predefinido de UpgradeReplicaSetCheckTimeout é diferente – veja Parâmetros de Atualização da Aplicação. Reverter no modo UnmonitoredManual funciona da mesma forma que avançar – a reversão será suspensa após concluir cada UD e terá de ser explicitamente retomada com Resume-ServiceFabricApplicationUpgrade para continuar com a reversão.

As reversões podem ser acionadas automaticamente quando as políticas de estado de funcionamento de uma atualização no modo Monitorizado com uma FalhaAção da Reversão são violadas (consulte Parâmetros de Atualização da Aplicação) ou explicitamente utilizando Start-ServiceFabricApplicationRollback.

Durante a reversão, o valor de UpgradeReplicaSetCheckTimeout e o modo ainda podem ser alterados em qualquer altura através de Update-ServiceFabricApplicationUpgrade.

Passos seguintes

Atualizar a aplicação com o Visual Studio orienta-o ao longo de uma atualização da aplicação com o Visual Studio.

Atualizar a aplicação com o PowerShell orienta-o ao longo de uma atualização da aplicação com o PowerShell.

Controle a forma como a sua aplicação é atualizada através dos Parâmetros de Atualização.

Torne as atualizações da sua aplicação compatíveis ao aprender a utilizar a Serialização de Dados.

Corrija problemas comuns nas atualizações de aplicações ao consultar os passos em Resolução de Problemas de Atualizações de Aplicações.