Upgrades do MID Server

Versão de lançamento: Xanadu

Atualizado 1 de ago. de 2024

13 min. de leitura

Faça upgrade dos MID Servers manualmente ou automaticamente na instância. O upgrade automático do MID Server é acionadao quando a instância é atualizada e o MID Server não tem mais a mesma versão. O novo pacote do MID Server é baixado em install.service-now.com, substitui o anterior e o MID Server é iniciado com a nova versão.

Aviso:

O MID Server não pode ser atualizado automaticamente em um host do Windows se o serviço de Experiência do Aplicativo do Windows estiver desligado. Para obter informações sobre o erro exibido e instruções para reativar esse serviço, consulte KB0597552.

Requisitos de upgrade do MID Server

Acesso ao site de download do MID Server: O computador host do MID Server deve ter acesso ao site de download da ServiceNow em install.service-now.com para fazer upgrade automaticamente. Se houver um ambiente ServiceNow auto-hospedado que bloqueie o acesso ao site de download, vai ser necessário importar manualmente o pacote do instalador do MID Server para os hosts do MID Server. Para obter instruções, consulte KB0760123 na base de conhecimento auto-hospedada.
Acesso do MID Server ao OCSP bloqueado: As configurações de firewall e proxy podem bloquear chamadas para o servidor OCSP Entrust, o que impede o funcionamento do MID Server. Pode ser necessário mudar as permissões do firewall para que o tráfego do OCSP passe corretamente. Para obter mais informações e resoluções, consulte o artigo da Base de Conhecimento HI [KB1216223].
Compatibilidade do sistema operacional com o MID Server: Não há suporte para o upgrade de MID Servers no Windows ou Linux com sistemas operacionais de 32 bits. Para obter mais informações, veja [KB0863694].

O MID Server não pode ser atualizado em um host do Windows se o serviço de Experiência do Aplicativo do Windows estiver desligado. Para obter informações sobre o erro exibido e instruções para reativar esse serviço, consulte KB0597552.

O upgrade do MID Server é bloqueado por alguns antivírus em execução nos hosts do Windows. Para obter informações sobre os erros e a lista desses antivírus consulte KB0870329.

Qualquer upgrade do MID Server no Linux cujo serviço esteja instalado no sistema Madrid ou inferior precisa reinstalar o serviço após o upgrade. Se você não tiver reinstalado manualmente o serviço em atualizações anteriores e se o serviço do MID Server ainda estiver instalado no sistema Madrid ou em versões inferiores, o MID Server reinstalará o serviço automaticamente durante o upgrade. Para reinstalar o serviço, o MID Server precisa ser executado como um usuário administrador. Caso seu upgrade do MID Server precise reinstalar o serviço, certifique-se de que o usuário do MID Server seja administrador ou reinstale manualmente o serviço antes da atualização. Para mais informações sobre como reinstalar o serviço manualmente, consulte KB0821436.

Quando o MID Server precisa de um upgrade

Todo MID Server que tenha uma versão diferente da versão da instância precisa ser atualizado. As duas propriedades do sistema abaixo controlam a versão de todos os MID Servers:

mid.buildstamp: identifica a versão do MID Server com um identificador baseado na data da compilação. Essa propriedade usa o formato mm-dd-aaaa-hhmm. O MID Server verifica as informações de versão de hora em hora. Se nenhuma versão de substituição estiver configurada, o MID Server examinará a propriedade mid.buildstamp da versão a ser usada. Essa propriedade é redefinida para a versão padrão (aquela que corresponde à versão da sua instância) quando a instância é reiniciada ou atualizada. Portanto, todas as mudanças do usuário são perdidas nesse momento. O sistema anexa o nome da versão e as informações do patch ao formato de data e hora.
Aviso:
Essa propriedade não fica visível por padrão e não deve ser configurada.
mid.version.override: define uma condição de substituição para a versão atual de todos os MID Servers em seu ambiente. Essa ação fixa os MID Servers em uma única versão e desativa o recurso de upgrade automático. Essa propriedade não fica visível no sistema de base e deve ser adicionada à tabela Propriedade do sistema [sys_properties] quando for definida. Para obter detalhes, consulte Como adicionar uma propriedade do sistema.

Quando os MID Servers verificam a versão a cada hora, eles examinam a propriedade mid.version.override primeiro. Se essa propriedade estiver vazia, os MID Servers obterão as informações de versão na propriedade mid.buildstamp. Se uma versão de substituição estiver configurada, os MID Servers usarão esse valor e ignorarão as informações de versão na propriedade mid.buildstamp. Esse valor de substituição permanece quando a instância é reiniciada e transmitida para os MID Servers. O valor na propriedade mid.version.override é apagado durante um upgrade, o que força o MID Server a se redefinir para a versão presente na propriedade mid.buildstamp.

Além de mid.version.override, a versão do MID Server também pode ser controlada com o parâmetro de configuração mid.pinned.version, que fixa o MID Server a uma versão específica. Para fixar um MID Server, defina o parâmetro mid.pinned.version com o nome da versão disponível no arquivo config.xml de cada MID Server. Use o formato <versão>-mm-dd-aaaa. Essa configuração substitui a configuração de propriedade da versão fixada do MID Server. Para obter instruções, consulte Como adicionar um parâmetro do MID Server. O valor definido nesse parâmetro não é afetado por um upgrade.

Aviso:

O uso de mid.version.override e mid.pinned.version não é recomendado. As diferentes versões no MID Server e na instância podem causar problemas de indisponibilidade no MID Server.

Métodos de upgrade

Automático

O upgrade automático pode ser acionado pela instância ou pelo próprio MID Server. Essa funcionalidade está disponível por padrão. O upgrade automático ocorre:

Quando a instância é atualizada e o MID Server para essa versão é diferente da versão atual do MID Server. A instância envia o comando do sistema autoUpgradepara os MID Servers conectados.
A cada hora, o MID Server verifica com a instância se há uma versão diferente disponível para upgrade. Não é possível modificar esse período.

Manual

Inicie manualmente o upgrade clicando em um link relacionado no registro do MID Server. Use esse método quando você não quiser esperar até a próxima atualização automática realizada a cada hora ou se o upgrade falhar e você quiser forçar uma atualização. Consulte Upgrade manual do MID Server para obter instruções.

Processo de upgrade

Verificação pré-upgrade: antes de iniciar o processo de upgrade do MID Server, esse servidor executa um conjunto de testes para garantir que a máquina host atenda aos requisitos mínimos. Todos os erros encontrados durante esse teste automático impedem o upgrade até que os problemas sejam resolvidos. O teste de pré-upgrade é ativado por padrão, mas pode ser desativado adicionando e definindo uma propriedade do sistema. Para obter mais informações, consulte Verificação de pré-upgrade do MID Server.
Download dos pacotes: o MID Server baixa os pacotes de upgrade em install.service-now.com. Esses pacotes estão no formato zip e são baixados para a pasta do agente na pasta package/incoming.
Verificação de assinatura digital
Depois de baixar cada pacote, o MID Server verifica a assinatura digital dele. Ele lança uma exceção se a verificação falha. O erro é registrado no log do agente e na tabela de problemas do MID Server.

Se os pacotes forem baixados e substituídos manualmente, você poderá verificar a assinatura de forma manual. Para verificar manualmente a assinatura de um pacote de instalação ou upgrade, use a ferramenta jarsigner, que está disponível gratuitamente com o JDK. Este é o comando jarsigner para iniciar a verificação: Jarsigner -verify -verbose -certs -strict <zip-file>
A saída deve ser semelhante ao exemplo a seguir:
```
- Signed by "CN=ServiceNow Inc., O=ServiceNow Inc., L=Santa Clara, ST=California, C=US"
Digest algorithm: SHA-256
Signature algorithm: SHA256withRSA, 2048-bit key
Timestamped by "CN=Symantec SHA256 TimeStamping Signer - G3, OU=Symantec Trust Network, O=Symantec Corporation, C=US" on Tue Nov 05 19:55:37 UTC 2019
Timestamp digest algorithm: SHA-256
Timestamp signature algorithm: SHA256withRSA, 2048-bit key
 
jar verified.
 
The signer certificate will expire on 2021-08-09.
The timestamp will expire on 2029-03-22.
```
Extração de arquivos zip: depois de baixar todos os pacotes necessários, o MID Server extrai os arquivos zip.
- Antes de Rome: os arquivos zip são extraídos para uma pasta temporária definida pelo sistema operacional. O nome da pasta é um número gerado aleatoriamente. A pasta temporária do sistema operacional é especificada pela propriedade do sistema java.io.tmpdir. Em um host UNIX, o valor dessa propriedade normalmente é /tmp ou /var/tmp.
- De Rome em diante: o MID Server evita o uso de pastas temporárias definidas pelo sistema operacional durante o upgrade do MID Server. Os arquivos zip são extraídos para uma pasta em work/upgrade_temp na pasta do agente. O formato do nome da pasta é um número gerado aleatoriamente. Se você quiser alternar para o comportamento anterior e usar uma pasta temporária definida pelo sistema operacional, poderá adicionar mid.upgrade.use_os_temp_folder ao arquivo config.xml do MID Server e defini-lo como true. Para mudar o comportamento de todos os MID Servers, adicione-o à propriedade [ecc_agent_property] do MID Server, deixando o campo MID Server em branco.
Nota:
Se você estiver usando o KB0747569 para mudar o java.io.tmpdir e quiser mantê-lo para atualizações futuras de Rome, configure mid.upgrade.use_os_temp_folder como true após a atualização para Rome. Se mid.upgrade.use_os_temp_folder não for configurado como verdadeiro, o java.io.tmpdir não será aplicado durante a atualização do MID Server e a pasta em agent\work\upgrade_temp será usada.
Substituição dos pacotes antigos pelos pacotes com upgrade: depois de baixar e extrair os pacotes de upgrade, o MID Server substitui os arquivos antigos pelos novos e inicia com a nova versão. Para substituir os pacotes, o MID Server inicia um processo chamado Upgrade de distribuição da plataforma ServiceNow e é encerrado. O Upgrade de distribuição da plataforma ServiceNow espera o MID Server ser encerrado corretamente e substitui os arquivos obrigatórios da seguinte forma:
- Antes do Rome: o processo exclui todos os arquivos e pastas localizados nas pastas bin, lib e jre e copia os novos arquivos para essas pastas.
- De Rome em diante: o processo substitui os arquivos nas pastas bin, lib e jre somente se a nova versão do arquivo for diferente da versão antiga. O Upgrade de distribuição da plataforma ServiceNow não apaga os arquivos de atualização e os arquivos inalterados são mantidos.
Se o serviço de reinstalação for necessário como parte da atualização do MID Server, o Upgrade de distribuição da plataforma ServiceNow reinstalará o serviço antes de iniciar o MID Server. Para obter mais informações, consulte KB0821436.
Nota:
Se o upgrade do MID Server falhar nesta etapa, o MID Server permanecerá inativo. Alguns antivírus bloqueiam a substituição do arquivo nessa etapa. Para obter mais informações, consulte KB0870329.
Inicialização do MID Server: depois de substituir todos os arquivos obrigatórios pela nova versão, o Upgrade de distribuição da plataforma ServiceNow inicia o MID Server. Quando o MID Server vem com a nova versão, ele apaga todas as pastas temporárias usadas para extrair os arquivos de upgrade.

Upgrade de mensagens de log

As mensagens de log do MID Server estão disponíveis nos seguintes arquivos de log:

As mensagens de log de verificação de pré-upgrade estão disponíveis no arquivo agent.log localizado na pasta agent/logs. A mensagem Executando testes de validação de pré-upgrade. indica que a verificação de pré-atualização foi iniciada. Se todos os testes obrigatórios forem aprovados, a mensagem Testes de validação de pré-upgrade bem-sucedidos. Continuando com o processo de upgrade. indica o fim da verificação de pré-upgrade.
Mensagens de log para baixar arquivos ausentes também estão disponíveis em agent.log. Cada download de pacote começa com a mensagem Baixando pacote em PACKAGENAME.ZIP em https://install.service-now.com/ PACKAGEINFO. O andamento do download e o tamanho do arquivo baixado são monitorados no log. Depois de baixar todos os pacotes, a mensagem O pacote foi baixado com êxito em https://install.service-now.com/ PACKAGEINFO indica que o download foi bem-sucedido.
A extração dos arquivos zip é a última etapa disponível em agent.log. A mensagem Atualizando o MID Server indica o início dessa etapa, e a mensagem Extraindo pacote PACKAGE.ZIP para EXTRACT_TMP_FOLDER é mostrada para cada extração de pacote. Quando todos os arquivos zip obrigatórios forem extraídos com sucesso, o servidor MID iniciará o processo de Upgrade de distribuição da plataforma ServiceNow e a mensagem Parando o MID Server. Inicializar o upgrade mostra o fim dessa etapa antes da desativação do MID Server.

Os logs de upgrade de distribuição da plataforma ServiceNow incluem mensagens de log para a inicialização do processo e para a substituição de arquivos durante a atualização do MID Server. As mensagens de log de upgrade são colocadas entre as mensagens *********** UPGRADE MAIN LOGIN START *********** e *********** UPGRADE MAIN LOGIN END ***********. As mensagens de log da upgrade de distribuição da plataforma ServiceNow podem ser encontradas nos seguintes arquivos de log:

No arquivo glide-dist-upgrade.log da pasta de extração temporária. Esse arquivo está disponível na pasta upgrade-wrapper/logs na pasta de extração temporária. Ele inclui mensagens de log de processo e mensagens de log de upgrade.
No arquivo dist-upgrade.log da pasta agent\logs. Esse arquivo inclui somente a parte de upgrade das mensagens de log. Se houver algum problema na inicialização do processo, você precisará consultar glide-dist-upgrade.log.
Em wrapper.log da pasta agent\logs. Depois de substituir os arquivos, a Atualização de distribuição da plataforma ServiceNow anexa o glide-dist-upgrade.log ao arquivo wrapper.log.

Atualize a configuração do wrapper com upgrade-wrapper-override.conf

A configuração do wrapper do glide-dist-upgrade pode ser atualizada usando um arquivo upgrade-wrapper-override.conf. Crie um arquivo chamado upgrade-wrapper-override.conf na pasta agent/conf. Todas as configurações no upgrade-wrapper-override.conf são usadas durante o processo de upgrade.

Ao modificar a configuração com upgrade-wrapper-override.conf, os logs de depuração podem ser habilitados no nível do wrapper dist-upgrade e as mudanças podem ser testadas.

Por exemplo, o tempo limite padrão pode não ser longo o suficiente para determinados comandos de nível de JVM. O tempo limite pode ser aumentado com upgrade-wrapper-override.conf para a configuração do wrapper dist-upgrade.

Estados do MID Server

Atualizando

O status do MID Server é alterado para Atualizando durante a execução do upgrade. O estado Atualizando é semelhante ao estado Pausado. Isso evita possíveis falhas de comunicação entre a nova versão da instância e a versão anterior do MID Server durante o upgrade. Enquanto o MID Server estiver no estado Atualizando, você não poderá retomá-lo ou reiniciá-lo. No entanto, você pode realizar as mesmas ações permitidas quando o MID Server está no estado Pausado.

Nota:

Se você estiver usando uma instância de Istanbul, mas estiver fazendo o upgrade um MID Server anterior para a versão Istanbul, esses estados de upgrade não ficarão disponíveis. Eles só ficam disponíveis para MID Servers que já estejam na versão Istanbul.

Falha no upgrade

Se o upgrade falhar na etapa de verificação de pré-atualização ou na etapa de download/extração de pacotes, as atualizações com falha serão tratadas de forma diferente com base na versão que você está atualizando.

Upgrade para outra versão principal (como Istanbul para a próxima versão completa): o status muda para Falha na atualização.
Upgrade de uma versão secundária em um lançamento (como do patch 1 de Jakarta para o patch 2): o MID Server continua usando a versão em execução no momento. Ele não executa o upgrade e o status muda para Ativo, supondo que o MID Server já esteja funcionando corretamente.
Se o upgrade falhar na última etapa, substituindo a versão antiga dos pacotes pela nova versão, o MID Server permanecerá Inativo.

Histórico de upgrades do MID Server

Use o módulo Histórico de upgrade do MID Server para solucionar problemas com atualizações do MID Server. O módulo contém um registro de cada upgrade de instância. Esses registros fornecem detalhes do status passo a passo para cada processo de upgrade do MID Server. Se ocorrer um erro, ele será anotado na etapa, e uma mensagem será gerada dinamicamente com mais detalhes. O trabalho de limpeza da tabela exclui automaticamente problemas que não foram detectados por 30 dias, independentemente do estado deles. Para obter mais informações, consulte Histórico de upgrade do MID Server.

Migração do certificado JRE TrustStore durante atualizações do JRE

Para atualizações do JRE após o upgrade para Quebec, o MID Server migra os certificados autoassinados existentes no JRE TrustStore para o TrustStore da nova versão do JRE. Quando esses certificados são migrados, os aliases deles são anexados com a cadeia de caracteres "snc_".

Para que um certificado seja migrado, ele deve:

ser um certificado x509
ser um certificado padrão v3
ter a extensão de restrição básica definida como false (ou seja, não deve ser emitida por uma CA)

O MID Server identifica quando um upgrade do JRE está prestes a ocorrer e inicia o processo de migração. Antes da migração, o MID Server cria um backup do TrustStore original como fallback em caso de falha. Se houver uma falha, o TrustStore de backup poderá ser restaurado manualmente.