Atualização do aplicativo Service Fabric: tópicos avançados

Artigo
08/25/2024

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

Se um novo tipo de serviço for adicionado a um aplicativo publicado como parte de uma atualização, o novo tipo de serviço será adicionado ao aplicativo implantado. Essa atualização não afeta nenhuma das instâncias de serviço que já faziam parte do aplicativo, mas uma instância do tipo de serviço que foi adicionado deve ser criada para que o novo tipo de serviço esteja ativo (consulte New-ServiceFabricService).

Da mesma forma, os tipos de serviço podem ser removidos de um aplicativo como parte de uma atualização. No entanto, todas as instâncias de serviço do tipo de serviço a ser removido devem ser removidas antes de prosseguir com a atualização (consulte Remove-ServiceFabricService).

Evite quedas de conexão durante o tempo de inatividade planejado do serviço sem monitoração de estado

Para tempos de inatividade de instância sem monitoração de estado planejados, como atualização de aplicativo/cluster ou desativação de nó, as conexões podem ser descartadas à medida que o ponto de extremidade exposto é removido depois que a instância fica inativa, o que resulta em fechamentos forçados de conexão.

Para evitar isso, configure o recurso RequestDrain adicionando uma duração de atraso de fechamento de instância na configuração de serviço para permitir que as solicitações existentes de dentro do cluster sejam drenadas nos pontos de extremidade expostos. Isso é conseguido à medida que o ponto de extremidade anunciado pela instância sem estado é removido antes do início do atraso antes do fechamento da instância. Esse atraso permite que as solicitações existentes sejam drenadas normalmente antes que a instância realmente caia. Os clientes são notificados da alteração do ponto de extremidade por uma função de retorno de chamada no momento do início do atraso, para que possam resolver novamente o ponto de extremidade e evitar o envio de novas solicitações para a instância que está inativa. Essas solicitações podem ser originadas de clientes que usam Proxy reverso ou usando APIs de resolução de ponto de extremidade de serviço com o modelo de notificação (ServiceNotificationFilterDescription) para atualizar os pontos de extremidade.

Configuração do serviço

Há várias maneiras 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 seção de padrões no manifesto do aplicativo, 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 por meio do modelo 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 de extremidade for alterado, os clientes devem registrar um retorno de chamada consulte Sample ServiceNotificationFilterDescription. A notificação de alteração é uma indicação de que os pontos de extremidade foram alterados, o cliente deve resolver novamente os pontos de extremidade, e não usar os pontos de extremidade que não são mais anunciados, pois eles cairão em breve.

Substituições de atualização opcionais

Além de definir durações de atraso padrão por serviço, você também pode substituir o atraso durante a atualização do aplicativo/cluster usando 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ído só se aplica à instância de atualização invocada e não altera as configurações individuais de atraso de serviço. Por exemplo, você pode usar isso para especificar um atraso de para ignorar quaisquer atrasos de atualização pré-configurados 0 .

Nota

As configurações para drenar solicitações não poderão impedir que o balanceador de carga do Azure envie novas solicitações para os pontos de extremidade que estão passando por drenagem.
Um mecanismo de resolução baseado em reclamações não resultará em drenagem normal de solicitações, pois aciona uma resolução de serviço após uma falha. Conforme descrito anteriormente, isso deve ser aprimorado para assinar as notificações de alteração de ponto de extremidade usando ServiceNotificationFilterDescription.
As configurações não são respeitadas quando a atualização é sem impacto, ou seja, quando as réplicas não serão derrubadas 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 de cluster FailoverManager.MaxInstanceCloseDelayDurationInSeconds, cujo padrão é 1800 segundos. Para atualizar o valor máximo, a configuração no nível do cluster deve ser atualizada. Essa configuração só está disponível na versão de tempo de execução 9.0 ou posterior.

Nota

Esse recurso pode ser configurado em serviços existentes usando o cmdlet Update-ServiceFabricService ou o modelo ARM, conforme mencionado acima, quando a versão do código do cluster estiver 7.1.XXX ou acima.

Modo de atualização manual

Nota

O modo de atualização monitorado é recomendado para todas as atualizações do Service Fabric. O modo de atualização Manual não monitorado só deve ser considerado para atualizações com falha ou suspensas.

No modo Monitorado , o Service Fabric aplica políticas de integridade para garantir que o aplicativo esteja íntegro à medida que a atualização progride. Se as políticas de integridade forem violadas, a atualização será suspensa ou revertida automaticamente, dependendo da FailureAction especificada.

No modo UnmonitoredManual , o administrador do aplicativo tem controle total sobre a progressão da atualização. Esse modo é útil ao aplicar políticas personalizadas de avaliação de integridade ou executar atualizações não convencionais para ignorar completamente o monitoramento de integridade (por exemplo, o aplicativo já está em perda de dados). Uma atualização em execução nesse modo será suspensa após a conclusão de cada UD e deverá ser explicitamente retomada usando Resume-ServiceFabricApplicationUpgrade. Quando uma atualização é suspensa e está pronta para ser retomada pelo usuário, seu estado de atualização mostrará RollforwardPending (consulte UpgradeState).

Finalmente, o modo UnmonitoredAuto é útil para executar iterações de atualização rápidas durante o desenvolvimento ou teste do serviço, uma vez que nenhuma entrada do usuário é necessária e nenhuma política de integridade do aplicativo é avaliada.

Atualizar com um pacote de comparação

Em vez de provisionar um pacote de aplicativo completo, as atualizações também podem ser executadas provisionando pacotes de comparação que contêm apenas os pacotes de código/configuração/dados atualizados, juntamente com o manifesto completo do aplicativo e os manifestos de serviço completos. Os pacotes de aplicativos completos são necessários apenas para a instalação inicial de um aplicativo no cluster. As atualizações subsequentes podem ser de pacotes de aplicativos completos ou pacotes de comparação.

Qualquer referência no manifesto do aplicativo ou manifestos de serviço de um pacote de comparação que não possa ser encontrada no pacote do aplicativo é automaticamente substituída pela versão atualmente provisionada.

Os cenários para usar um pacote de comparação são:

Quando você tem um pacote de aplicativo grande que faz referência a vários arquivos de manifesto de serviço e/ou vários pacotes de código, pacotes de configuração ou pacotes de dados.
Quando você tem um sistema de implantação que gera o layout de compilação diretamente do processo de compilação do aplicativo. Nesse caso, mesmo que o código não tenha sido alterado, os assemblies recém-criados obtêm uma soma de verificação diferente. Usar um pacote de aplicativo completo exigiria que você atualizasse a versão em todos os pacotes de código. Usando um pacote de comparação, você fornece apenas os arquivos que foram alterados e os arquivos de manifesto onde a versão foi alterada.

Quando um aplicativo é atualizado usando o Visual Studio, um pacote de comparação é publicado automaticamente. Para criar um pacote de comparação manualmente, o manifesto do aplicativo e os manifestos de serviço devem ser atualizados, mas apenas os pacotes alterados devem ser incluídos no pacote de aplicativo final.

Por exemplo, vamos começar com o seguinte aplicativo (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 você queria atualizar apenas o pacote de código de service1 usando um pacote diff. Seu aplicativo atualizado 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

Nesse caso, você atualiza o manifesto do aplicativo para 2.0.0 e o manifesto de serviço para service1 para refletir a atualização do pacote de código. A pasta para o seu pacote de aplicativo teria a seguinte estrutura:

app1/
  service1/
    code/

Em outras palavras, crie um pacote de aplicativo completo normalmente e, em seguida, remova todas as pastas de pacote de código/configuração/dados para as quais a versão não foi alterada.

Atualize os parâmetros do aplicativo independentemente da versão

Às vezes, é desejável alterar os parâmetros de um aplicativo do Service Fabric sem alterar a versão do manifesto. Isso pode ser feito convenientemente usando o sinalizador -ApplicationParameter com o cmdlet Start-ServiceFabricApplicationUpgrade do Azure Service Fabric PowerShell. Suponha um aplicativo 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 o aplicativo usando o cmdlet Start-ServiceFabricApplicationUpgrade . Este exemplo mostra uma atualização monitorada, mas uma atualização não monitorada também pode ser usada. Para ver uma descrição completa dos sinalizadores aceitos por este cmdlet, consulte a referência do módulo 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 se o aplicativo 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 aplicativos

Embora as atualizações possam ser roladas para frente em um dos três modos (Monitored, UnmonitoredAuto ou UnmonitoredManual), elas só podem ser revertidas no modo UnmonitoredAuto ou UnmonitoredManual. A reversão no modo UnmonitoredAuto funciona da mesma forma que a rolagem para frente, com a exceção de que o valor padrão de UpgradeReplicaSetCheckTimeout é diferente - consulte Parâmetros de atualização do aplicativo. A reversão no modo UnmonitoredManual funciona da mesma forma que a rolagem para frente - a reversão será suspensa após a conclusão de cada UD e deve ser explicitamente retomada usando Resume-ServiceFabricApplicationUpgrade para continuar com a reversão.

As reversões podem ser acionadas automaticamente quando as políticas de integridade de uma atualização no modo Monitorado com uma FailureAction of Rollback são violadas (consulte Parâmetros de atualização do aplicativo) ou explicitamente usando Start-ServiceFabricApplicationRollback.

Durante a reversão, o valor de UpgradeReplicaSetCheckTimeout e o modo ainda podem ser alterados a qualquer momento usando Update-ServiceFabricApplicationUpgrade.

Próximos passos

Atualizando seu aplicativo usando o Visual Studio orienta você através de uma atualização de aplicativo usando o Visual Studio.

Atualizando seu aplicativo usando o PowerShell orienta você por uma atualização de aplicativo usando o PowerShell.

Controle como seu aplicativo é atualizado usando os Parâmetros de Atualização.

Torne as atualizações do seu aplicativo compatíveis aprendendo a usar a Serialização de Dados.

Corrija problemas comuns em atualizações de aplicativos consultando as etapas em Solução de problemas de atualizações de aplicativos.

Partilhar via

Atualização do aplicativo Service Fabric: tópicos avançados

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

Evite quedas de conexão durante o tempo de inatividade planejado do serviço sem monitoração de estado

Configuração do serviço

Configuração do cliente

Substituições de atualização opcionais

Modo de atualização manual

Atualizar com um pacote de comparação

Atualize os parâmetros do aplicativo independentemente da versão

Reverter atualizações de aplicativos

Próximos passos

Comentários

Recursos adicionais