Etapas de patch de tempo de inatividade zero do SharePoint Server
APLICA-SE A:
2013 
2019 Subscription Edition SharePoint no Microsoft 365
O ZDP (patching de tempo de inatividade zero) está disponível no SharePoint Server 2016, SharePoint Server 2019 e Edição de Assinatura do SharePoint Server. Permitir que os usuários continuem trabalhando, salvando e pesquisando documentos enquanto você corrija seu farm do SharePoint Server.
O patch de tempo de inatividade zero é um método de patch 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).
Sua experiência ZDP pode ser aprimorada usando MinRole no SharePoint Server, mas MinRole não é um requisito.
É preciso que seu farm aproveite a alta disponibilidade (HA) para ter os benefícios da ZDP. Um farm do SharePoint Server altamente disponível é um requisito para ZDP.
É 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 em seu farm do SharePoint Server tenham sido configurados para usar a função 'Custom', você ainda poderá configurar manualmente um farm altamente disponível. Há artigos que ajudarão você a construir fazendas altamente disponíveis, e os princípios de tolerância a falhas (ter hardware redundante) e alta disponibilidade (ter sistemas e software em vigor para dar suporte ao failover e à continuação do tempo de atividade) são os mesmos. Lembre-se de que, em fazendas altamente disponíveis ou personalizadas mais complexas, você deve ter um cuidado especial para corrigir os servidores de Pesquisa de uma maneira que dê suporte à HA, por exemplo, corrigir uma réplica de índice por vez e nunca corrigir ou atualizar réplicas de índice da mesma partição ao mesmo tempo.
O processo de ZDP
Este exemplo usa o ZDP em uma configuração de farm do SharePoint Server usando MinRole. O ambiente do exemplo é semelhante a:
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
Informações gerais sobre software Atualizações para SharePoint Server podem ser encontradas aqui. Observe que o artigo é vinculado à documentação nas configurações de permissões para o 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 é integrado ao PSCONFIG, mas deve ser habilitado. 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 habilitar a funcionalidade lado a lado, execute o seguinte script do PowerShell uma vez usando a URL de um dos aplicativos Web de conteúdo:
$webapp = Get-SPWebApplication <webappURL>
$webapp.WebService.EnableSideBySide = $true
$webapp.WebService.update()
A partir do KB3178672 (atualização de março de 2017) para o SharePoint Server 2016 e superior, o PSCONFIG copiará automaticamente todos os arquivos .js, .css e .htm dentro 16-HIVE\TEMPLATE\LAYOUTS da pasta para a 16-HIVE\TEMPLATE\LAYOUTS\<NEW BUILD NUMBER> pasta, necessário para poder alternar para os novos arquivos de interface do usuário e concluir o processo lado a lado, conforme descrito posteriormente 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.
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.
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.
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).
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
Cada nó no farm do SharePoint Server tem 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.
Retorne ao WFE que está fora da rotação balanceada por carga (SPWeb02), abra o Shell de Gerenciamento do SharePoint e execute este comando PSCONFIG:
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -installDepois que o comando tiver concluído, devolva esse WFE (SPWeb02) para o balanceador de carga. Esse servidor estará totalmente corrigido e atualizado.
Dica
A última etapa no processo PSCONFIG garante que as atualizações para a interface do usuário (interface do usuário) sejam copiadas da pasta /layouts para uma pasta específica da versão. Isso faz parte da atualização de interface do usuário lado a lado que permite que os usuários que navegam em seu farm tenham uma experiência da interface do usuário até que a atualização seja concluída e você 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 padrão, isso está localizado em:
C:\arquivos de programa\arquivos comuns\Microsoft shared\extensões do servidor Web\16\logs. (A letra da sua unidade raiz pode variar!)
Se, por algum motivo, o PSCONFIG não tiver copiado arquivos da interface do usuário com êxito, execute este comando para copiá-los manualmente Copy-SidebySideFiles!
Remova o SPWeb01 do balanceador de carga. > Abra o Shell de Gerenciamento do SharePoint e execute o mesmo comando PSCONFIG:
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -installDevolva 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.
Para todos os servidores restantes na coluna 1 (SPApp01, SPDCH01, SPSRCH01), execute o mesmo comando PSCONFIG no Shell de Gerenciamento 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
Para todos os servidores restantes na coluna 2 (SPApp02, SPDCH02, SPSRCH02), execute o mesmo comando PSCONFIG no Shell de Gerenciamento 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 -installImportante
Depois que todos os servidores tiverem passado pelo PSCONFIG com êxito, lembre-se de executar o comando Shell de Gerenciamento do SharePoint abaixo para alternar para os novos arquivos de interface do usuário 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 Edição de Assinatura do SharePoint Server. 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?
O HA é um tópico amplo no SharePoint. Há whitepapers inteiros e artigos sobre isso online, como esta documentação. Para simplificar o conceito, pelo menos para este artigo, perceba que o ZDP (e também o MinRole) se originou no SharePoint no Microsoft 365. No SharePoint no Microsoft 365, os servidores virtualizados têm redundâncias internas, de modo que dois da mesma função de servidor do mesmo farm do SharePoint não viverão no mesmo host ou rack. Isso torna o SharePoint mais tolerante a falhas. Você pode modelar a mesma situação tendo duas de cada função do SharePoint Server em hosts separados em racks diferentes em seu próprio datacenter, com um roteador compartilhado ou cabeamento entre racks para fazer uma comunicação mais rápida. Você também pode simplesmente ter dois servidores físicos para cada função do SharePoint Server configurada em um ambiente de teste (escolhendo barras de energia separadas para cada metade do farm e certificando-se de que o roteamento entre o conjunto de servidores é rápido e, se possível, ignora o tráfego de rede mais amplo para menor latência).
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 hora de planejar o ZDP, você deve desenhar seu próprio ambiente, onde quer que ele more (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.
Tópicos Relacionados
Demonstração em vídeo da Correção de Nenhum Tempo de Inatividade no SharePoint Server 2016