Compartilhar via

Passos de aplicação de patches sem tempo de inatividade do SharePoint Server

  • Artigo

APLICA-SE A:no-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint no Microsoft 365

A aplicação de patches sem tempo de inatividade (ZDP) está disponível no SharePoint Server 2016, SharePoint Server 2019 e SharePoint Server Subscription Edition. Permita que os utilizadores continuem a trabalhar, a guardar e a procurar documentos à medida que corre o seu farm do SharePoint Server.

A aplicação de patches sem tempo de inatividade é um método de aplicação de patches e atualização desenvolvido no SharePoint no Microsoft 365. Ela foi feita para permitir que os administradores corrijam o serviço enquanto os usuários continuam a usar a assinatura deles. Em outras palavras, esse método testado foi desenvolvido para permitir a correção enquanto as pessoas trabalham ativamente em seus arquivos e pesquisam rastreamentos e renderizam resultados no farm do SharePoint Server. Isso é o que significa 'tempo de inatividade zero'.

Alguns pontos devem ser observados enquanto discutimos a ZDP (falaremos mais sobre esses elementos posteriormente neste artigo).

É importante lembrar que o objetivo da ZDP é o tempo de atividade de seus usuários. Portanto, neste artigo, todas as decisões envolvidas na correção e na reinicialização de seu farm deverão ser realizadas com esse fator em mente.

Importante

Mesmo que todos os servidores no farm do SharePoint Server tenham sido configurados para utilizar a função "Personalizado", ainda pode configurar manualmente um farm de elevada disponibilidade. Existem artigos que irão ajudá-lo a construir farms de elevada disponibilidade e os princípios de tolerância a falhas (com hardware redundante) e elevada disponibilidade (ter sistemas e software implementados para suportar a ativação pós-falha e a continuação do tempo de atividade) são os mesmos. Tenha em atenção que, em farms altamente disponíveis ou personalizados mais complexos, deve ter especial cuidado para corrigir os servidores de Pesquisa de uma forma que suporte HA, por exemplo, corrigir uma réplica de índice de cada vez e nunca aplicar patches ou atualizar réplicas de índice da mesma partição ao mesmo tempo.

O processo de ZDP

Este exemplo utiliza o ZDP numa configuração de farm do SharePoint Server com o MinRole. O ambiente do exemplo é semelhante a:

The environment for this article has 8 servers: 4 required server roles in column 1 (SPWeb01, SPApp01, SPDch01, SPSrch01) and 4 redundant server roles in column 2 (SPWeb02, SPApp02, SPDch02, SPSrch02).

Ao decompor essa estrutura, vemos que há dois front-ends da Web (WFEs) (SPWeb01 e 02) conectados a um balanceador de carga, e ambos estão recebendo e respondendo solicitações neste momento. Existem dois Servidores de Aplicativos (SPApp01 e 02), dois Servidores de Cache Distribuído (SPDCH01 e 02) e dois Servidores de Pesquisa (SPSRCH01 e 02). Atrás dessa estrutura, mas não diretamente incluído no processo de ZDP, há um cluster de SQL Server (por exemplo, o SQL Server Always-On).

Obviamente, você pode desenhar uma linha no meio do farm nesse diagrama, de cima para baixo. De um lado estão todos os servidores com final '01' (coluna 1) e de outro, os servidores redundantes, com final em '02' (coluna 2). Usaremos essa construção dupla para manter o farm preparado para os usuários durante a correção.

Em grande parte, tudo o que você fizer de um lado (nos servidores 01), deverá ser feito exatamente nos servidores 02. As etapas envolvidas no processo de duas fases da ZDP são relativamente simples, porém, os passos com relação aos WFEs (SPWeb01 e 02) são mais complexos. Começaremos, então, daí.

Observação

Pode encontrar informações gerais sobre Atualizações de Software para o SharePoint Server aqui. Repare que o artigo estabelece ligação para a documentação sobre as definições de permissões do SharePoint Server. Examine esses artigos conforme necessário e lembre-se de que parte da correção envolve a atualizações do banco de dados. Se você alterou as permissões do SQL Server para contas do SharePoint após a instalação, por exemplo, você precisará consultar esses artigos.

Não deixe de reiniciar e testar seus WFEs antes retirá-los do balanceador de carga para evitar situações em que o WFE a ser corrigido primeiro é retirado de rotação, e os outros WFEs não conseguem lidar com a carga resultante. Todos os servidores no farm devem reiniciados previamente e devem estar corretos antes da correção. Além disso, considere parar os Rastreamentos de Pesquisa e as Importações de Perfil durante a atualização ou a janela de correção.

Importante

A execução lado a lado garante que todos o front-ends da Web, no farm, sirvam ao mesmo conteúdo estático durante a atualização, mesmo se os arquivos estáticos em um determinado WFE estão sendo atualizados ou substituídos. Lado a lado está incorporado em PSCONFIG, mas tem de estar ativado. Esse recurso garante que os usuários tenham a mesma experiência dos sites ao navegar no SharePoint e ao trabalhar em seus arquivos, mesmo quando os arquivos do sistema estão sendo alterados ou atualizados.

Para ativar a funcionalidade lado a lado, execute o seguinte script do PowerShell uma vez com o URL de uma das aplicações Web de conteúdo:

$webapp = Get-SPWebApplication <webappURL>
$webapp.WebService.EnableSideBySide = $true
$webapp.WebService.update()

A partir de KB3178672 (atualização de março de 2017) para o 16-HIVE\TEMPLATE\LAYOUTS SharePoint Server 2016 e superior, o PSCONFIG copiará automaticamente todos os ficheiros .js, .css e .htm na pasta para a 16-HIVE\TEMPLATE\LAYOUTS\<NEW BUILD NUMBER> pasta, necessário para poder mudar para os novos ficheiros de interface de utilizador e concluir o processo lado a lado, conforme descrito mais adiante neste tópico na Fase 2 – Atualização PSCONFIG (4).

Fase 1: instalação de patches

A primeira fase é instalar os binários de patch nos servidores.

  1. A etapa 1 do processo de aplicação de patch para tempo de inatividade zero é exibida em um gráfico.

    Remova o primeiro WFE (SPWeb01) do balanceador de carga e aplique o patch com os pacotes de 'STS' e 'WSS'.
    Reinicie o servidor quando a aplicação de patch estiver concluída.
    Devolva o servidor à rotação no balanceador de carga.

  2. Etapa 2 do processo de aplicação de patch para tempo de inatividade zero.

    Remova o segundo WFE (SPWeb02) do balanceador de carga e aplique o patch com os pacotes de 'STS' e 'WSS'.
    Reinicie o servidor quando a aplicação de patch estiver concluída.
    Deixe esse servidor fora do balanceador de carga até que a atualização completa esteja concluída.

    Observação

    Se você não estiver executando a atualização em uma janela de manutenção e o farm tiver muita carga, você poderá devolver esse WFE ao balanceador de carga de rede até que esteja tudo pronto para executar o PSCONFIG.

  3. A etapa 3 do processo de aplicação de patch para tempo de inatividade zero é exibida em um gráfico.

    Para cada um dos SPApp, SPDCH e SPSRCH, na coluna 1, aplique os patches com pacotes 'STS' e 'WSS'.
    Reinicialize-os quando tiverem concluído a tarefa. (O trabalho enviado pelo SPWeb01 será lançado nos servidores da coluna 2).

  4. A etapa 4 do processo de aplicação de patch para tempo de inatividade zero é exibida no gráfico.

    Agora você deverá repetir 'a aplicação de patch e a reinicialização' na coluna 2. Para cada um dos SPApp02, SPDCH02 e SPSRCH02, na coluna 2, aplique os patches com pacotes 'STS' e 'WSS'.
    Reinicialize-os quando tiverem concluído a tarefa. (Como pode ver, o trabalho enviado pelo SPWeb01 será agora lançado nos servidores da coluna 1).

Fase 2: atualização do PSCONFIG

Todos os nós no farm do SharePoint Server têm os patches instalados e todos foram reiniciados. Esta na hora de fazer a compilação para a atualização.

Observação

[!OBSERVAçãO] Durante o processo de ZDP, você pode executar o Upgrade-SPContentdatabase para reduzir o tempo total necessário para concluir a execução do PSCONFIG. Considere fazer isso se você tiver um grande número de bancos de dados ou selecione grandes bancos de dados.

  1. O passo 5 no processo ZDP é apresentado num gráfico.

    Regresse ao WFE que está fora da rotação com balanceamento de carga (SPWeb02), abra a Shell de Gestão do SharePoint e execute este comando PSCONFIG:

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install

    Depois que o comando tiver concluído, devolva esse WFE (SPWeb02) para o balanceador de carga. Esse servidor estará totalmente corrigido e atualizado.

    Dica

    O último passo no processo PSCONFIG garante que as atualizações para a Interface de Utilizador (IU) são copiadas da pasta /layouts para uma pasta específica da versão. Isto faz parte da atualização da IU lado a lado que permite que os utilizadores que navegam no farm tenham uma experiência da IU até que a atualização esteja concluída e que esteja pronto para mudar para a nova interface.
    Para garantir que a cópia lado a lado seja bem-sucedida, verifique o arquivo de log associado. Por predefinição, está localizado em:
    C:\program files\common files\Microsoft shared\web server extensions\16\logs. (A letra da sua unidade raiz pode variar!)
    Se, por algum motivo, o PSCONFIG não tiver copiado ficheiros de IU com êxito, execute este comando para os copiar manualmente Copy-SidebySideFiles!

  2. A etapa 6 do processo de aplicação de patch para tempo de inatividade zero é exibida no gráfico.

    Remova o SPWeb01 do balanceador de carga. > Abra a Shell de Gestão do SharePoint e execute o mesmo comando PSCONFIG:

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install

    Devolva esse WEF (SPWeb01) ao balanceador de carga. Esse servidor também estará totalmente corrigido e atualizado.

    Ambos os WFEs estarão corrigidos e atualizados. Prossiga para o restante do farm, mas verifique se os comandos necessários do Microsoft PowerShell estão em execução em um servidor de cada vez e não em paralelo. Isso quer dizer que você executará os comandos em um servidor da coluna 1 de cada vez. Em seguida, você irá executar os comandos em um servidor da coluna 2 de cada vez e não sobrepondo-os. O objetivo final é a preservação do tempo de atividade. Executar os comandos do PSCONFIG em série é a forma mais previsível e segura de concluir o processo de ZDP, portanto, é o que faremos.

  3. A etapa 7 do processo de aplicação de patch para tempo de inatividade zero é exibida no gráfico.

    Para todos os servidores restantes na coluna 1 (SPApp01, SPDCH01, SPSRCH01), execute o mesmo comando PSCONFIG na Shell de Gestão do SharePoint. Faça isso em um servidor de cada vez, até que todos os servidores da coluna 1 sejam atualizados.

    Importante

    Lembre-se de remover o Cache Distribuído antes de executar o PSCONFIG e adicionar novamente o Cache Distribuído ao servidor após a conclusão.

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install

  4. A etapa 8 do processo de aplicação de patch para tempo de inatividade zero é exibida no gráfico.

    Para todos os servidores restantes na coluna 2 (SPApp02, SPDCH02, SPSRCH02), execute o mesmo comando PSCONFIG na Shell de Gestão do SharePoint. Faça isso em um servidor de cada vez, até que todos os servidores da coluna 2 sejam atualizados.

    Importante

    Lembre-se de remover o Cache Distribuído antes de executar o PSCONFIG e adicionar novamente o Cache Distribuído ao servidor após a conclusão.

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install

    Importante

    Depois de todos os servidores terem passado por PSCONFIG com êxito, lembre-se de executar o comando Shell de Gestão do SharePoint abaixo para mudar para os novos ficheiros de interface de utilizador e concluir o processo lado a lado:
    $webapp = Get-SPWebApplication <webappURL> $webapp.WebService.SideBySideToken = <current build number in quotes, ex: "16.0.4338.1000">
    $webapp.WebService.update()

Pronto, você terminou. O farm foi totalmente atualizado em uso e sem tempo de inatividade.

Por que o MinRole pode ajudar?

Ao falar sobre a ZDP é também necessário abordar o conceito de MinRole. MinRole é uma opção na instalação do SharePoint Server 2016, SharePoint Server 2019 e SharePoint Server Subscription Edition. Ele divide a configuração de um farm em funções como Front End (WFE), Servidor de Aplicativos (App), Cache Distribuído (DCache), Pesquisa ou Personalização (para produtos de código ou de terceiros personalizados). Essa configuração lhe dará quatro servidores em média, dois WFEs, dois Servidores de Aplicativos, dois Servidores de DCache e dois Servidores de Pesquisa.

Por padrão, os WFEs são ajustados para baixa latência, e os Servidores de Aplicativos para alta produtividade. Da mesma forma, agrupar os componentes de pesquisa para que as chamadas não precisem sair da caixa em que elas se originam faz com que os Servidores de Pesquisa trabalhem com mais eficiência. Um dos maiores benefícios do MinRole é que ele está integrado na tolerância a falhas.

Por que a Alta Disponibilidade é necessária?

A HA é um tópico abrangente no SharePoint. Existem documentos técnicos e artigos completos sobre o mesmo online, como esta documentação. Para simplificar o conceito, pelo menos para este artigo, tenha em atenção que o ZDP (e também o MinRole) teve origem no SharePoint no Microsoft 365. No SharePoint no Microsoft 365, os servidores virtualizados têm redundâncias incorporadas, para que duas das mesmas funções do servidor do mesmo farm do SharePoint não residam no mesmo anfitrião ou rack. Isto torna o SharePoint mais tolerante a falhas. Pode modelar a mesma situação ao ter duas de cada função do SharePoint Server em anfitriões separados em racks diferentes no seu próprio datacenter, com um router partilhado ou cablagem entre racks para criar uma comunicação mais rápida. Também pode simplesmente ter dois servidores físicos para cada função do SharePoint Server configuradas num ambiente de teste (escolher barras de energia separadas para cada metade do farm e garantir que o encaminhamento entre o conjunto de servidores é rápido e, se possível, ignora o tráfego de rede mais amplo para uma latência mais baixa).

Os objetivos aqui são a alta disponibilidade e a tolerância a falhas. Isso significa que as prioridades principais são separar as funções entre racks ou servidores, ter certeza de que há dois deles de cada função, facilitar o tráfego de rede rápido entre essas duas camadas e garantir que sua configuração possui sistemas em funcionamento para monitorar e fazer o failover automático dos servidores de banco de dados. A respeito da instalação manual dos serviços do SharePoint (como quando escolher a função 'Personalizado'), é importante que os serviços tenham redundância dentro do farm. Por exemplo, o Cache Distribuído é agrupado, seu farm tem vários WFEs, você configura servidores de Aplicativos e de Pesquisa em pares. Dessa forma, no caso de ocorrer um problema sério em um servidor, o outro pode processar a carga de usuário.

Nos exemplos usados aqui, foram desenhados servidores físicos para tornar os entendimento dos conceitos mais fáceis. Quando chegar a altura de planear o ZDP, deve desenhar o seu próprio ambiente, onde quer que esteja (completo com nomes/números de rack e nomes de servidor onde cada função do SharePoint Server pode ser encontrada). Essa é uma das maneiras mais rápidas para isolar qualquer violação dos objetivos de redundância de função e de tolerância a falhas que pode ter entrado furtivamente em sua configuração, independentemente do tamanho dela.

Demonstração em vídeo da Correção de Nenhum Tempo de Inatividade no SharePoint Server 2016