Guia para atualização do BroadWorks 22.0

Introdução

Este documento descreve considerações e requisitos para ajudar no planejamento de uma atualização a partir da versão de origem do BroadWorks 2.0.

Overview

O BroadWorks Versão 2.0 suporta atualizações para versões 23.0 e 24.0. A versão 22.0 está no fim da manutenção (EoM), 23.0 está no fim de julho de 2024 e 24.0 EoM está previsto para o fim de julho de 2026. A atualização para 24.0 é o caminho recomendado.

Versões independentes de lançamento

A partir da versão 23.0, o MS é Independente de Versão (RI) e na versão 24.0 todos os servidores, exceto o AS Versão Independente. Todos os novos recursos, bugs e correções de segurança são fornecidos em uma nova versão. Os patches não estão disponíveis; em vez disso, os servidores precisam ser atualizados de uma versão para outra para obter uma correção. Uma nova versão de cada servidor é lançada a cada mês (em vez de pacotes de patches mensais) ou com mais frequência se uma correção urgente for necessária.

As versões de RI usam um formato diferente do formato padrão Rel_24.0_1.944. Este formato de RI é Server_Rel_yyy.mm_x.xxx:

• O servidor é MS, por exemplo:
• aaaa é o ano de 4 dígitos
• mm é o mês de 2 dígitos
• x.xxx é a versão incremental para esse mês

MS_Rel_2022.11_1.273.Linux-x86_64.bin é uma versão do MS lançado em novembro de 2022. Frequentemente, é abreviado como 2022.11 se não se referir a um tipo de servidor específico ou versão incremental.

Requisitos do sistema operacional

Verifique se o sistema operacional (SO) de origem é suportado pela versão de destino.

Os sistemas operacionais compatíveis são Red Hat Enterprise Linux, Oracle Linux e CentOS 7. Não há suporte para CentOS 8, CentOS Stream, Rocky Linux e Alma Linux.

O suporte ao Linux 6 terminou em 30 de abril de 2023 com o 2023.05.
O suporte ao Linux 7 termina em 20 de junho de 2024 com 2024.07.

O suporte ao Linux 9 está disponível a partir de 2023.09+.

Versões principais do Linux suportadas

R22: 5.9+, 6.5+, 7
R23: 5.9+, 6.5+, 7 e 8.x (ap385046 necessário)
R24: 6,5+, 7, 8

Versões independentes de versão do Linux suportadas

2018.01+: 5.9+, 6.5+, 7
2019.10+: 6,5+, 7
2020,07+: 6,5+, 7, 8
2023.05+: 7, 8
2023.09+: 7, 8, 9

Versões Linux com Suporte do DBS (Database Server)

DBS R22: 5.9+, 6.5+
DBS 2018.11 a 2020.08: 6,5+, 7
DBS 2020.11 a 2022.06: somente 7.5+
DBS 2022.07+: 7.5+, 8.5+

Atualizações do SO

A BroadWorks não suporta um upgrade in-loco entre as principais versões do Linux. É recomendável executar uma troca de hardware, criar um novo servidor na versão Linux de destino e migrar o servidor existente para o novo servidor. Consulte a seção 5.2.6 do Guia de Gerenciamento de Software e a seção 12.2 do Guia de Manutenção.

Não é recomendável usar uma troca de hardware para atualizar a BroadWorks ao mesmo tempo ou para executar uma troca de hardware e a atualização da BroadWorks na mesma janela de manutenção. Os servidores com um banco de dados devem passar pelo processo de atualização; um banco de dados de uma versão do BroadWorks não pode ser importado para outra versão do BroadWorks.

Limitações de atualização e observações específicas do servidor

Atualização do servidor de perfil e da plataforma de serviço estendida para a plataforma de fornecimento de aplicativos

A partir da versão 24.0, o servidor de perfil (PS) e a plataforma de serviços estendidos (XSP) se tornam o mesmo tipo de servidor, conhecido como plataforma de fornecimento de aplicativos (ADP). Os servidores PS e XSP são atualizados e se tornam o tipo de servidor ADP após a atualização.

Uma licença ADP e uma versão atualizada dos aplicativos implantados são necessárias. As atualizações de XSP devem ocorrer após a atualização dos servidores de aplicativos (AS). Há versões RI do PS e XSP no portal de download, mas elas são apenas para sistemas que implantam o servidor do servidor de execução (XS) no lugar do AS. Todos os sistemas com um AS devem atualizar PS e XSPs para ADP.

Os aplicativos Cisco BroadWorks e os aplicativos da Web precisam ser atualizados manualmente no XSP, PS e ADP.

Servidor de banco de dados

O Servidor de Banco de Dados (DBS) deve ser atualizado em vários saltos para atualizar para a versão mais recente do RI devido a restrições do SO. O DBS 22.0 suporta Linux 5 e 6. Se estiver executando o Linux 5, o DBS não poderá fazer upgrade além da versão 2.0. Versões As versões independentes do DBS não suportam Linux 5. Se estiver executando o Linux 6, o DBS poderá atualizar para 2020.08. Em seguida, o DBS deve fazer a troca de hardware para o Linux 7, onde poderá fazer o upgrade novamente. Ao atualizar o DBS e o PS, as versões do DBManagement e do DBSObserver devem corresponder à versão do DBS para garantir que a versão subjacente do Oracle seja compatível.

Versão do DBS e Alinhamento da Versão do Oracle

22.0: Oracle 11
de 2018.11 a 2020.08: Oracle 12
2020.11+: Oracle 19

Ignorando a Atualização de DBS

Há uma opção para ignorar a atualização do DBS e importar o DB de 22.0 diretamente para o DBS 2022.03+. No entanto, esse processo não é rápido e deve ser testado no laboratório para verificar o tempo esperado para produção. Consulte a seção 6 das Notas de versão do DBS, BWKS-3069 e a seção 6.5.7.3 do Guia de configuração do DBS.

Registros de chamadas melhorados

O Enhanced Call Logs (ECL) é o fim da vida útil no DBS após o DBS 2020.08. O banco de dados ECL deve ser migrado para um Servidor de banco de dados de rede (NDS) para uso contínuo; a migração não é automática. Consulte o Guia da solução Enhanced Call Logs e a Descrição do recurso NDS Enhanced Call Logs para obter mais informações. Consulte o Guia de Configuração do Servidor de Banco de Dados de Rede para configurar um NDS e a Descrição do Recurso Migração de DBS para NDS para obter o procedimento de migração. A migração deve ser executada antes da atualização.

Colaborar com servidores

O Fim da Manutenção (EoM) para o Servidor de Mensagens (UMS), Servidor de Compartilhamento (USS), Servidor de Vídeo (UVS), Servidor WebRTC (WRS), Cliente Business Communicator (BTBC) e Cliente Connect foi em 31 de janeiro de 2022. A última versão de RI disponível para o UMS é 22.0 e para o USS, UVS e WRS a última disponível é 2022.01.

O AS em 24.0 é compatível com o UMS em 22.0 e 21.sp1. Não é recomendável atualizar o UMS para 2.0. O UMS em 22.0 usa MariaDB em vez do Oracle TimesTen, necessitando de etapas adicionais para fazer upgrade, tem um Método de Procedimento (MOP) separado e requer um nó adicional para redundância. Consulte o UMS Upgrade MOP e a Notificação de Campo sobre o Fim da Vida Útil do MariaDB 10.1.

É recomendável substituir os serviços do Collaborate pelo WebEx para BroadWorks. Consulte o Guia de Soluções do WebEx para BroadWorks.

Sistema de gerenciamento de elementos e servidor de licenciamento virtual

O Sistema de Gerenciamento de Elementos (EMS - Element Management System) e o Servidor de Licenciamento Virtual (VLS - Virtual Licensing Server) estão no Fim da Vida Útil (EoL - End of Life) a partir do segundo trimestre de 2018 e sua funcionalidade foi substituída pelo Network Function Manager (NFM - Gerenciador de Função de Rede). Não há caminho de atualização para o NFM ou desativação de nenhum nó EMS ou VLS.

Gerenciador de funções de rede

Se o Monitoramento de rede for implantado, haverá uma etapa adicional necessária; da 22.0, atualize para 2020.11 e depois para 2022.08+.

Atualizando para 23.0 no Linux 6

Se for feito o upgrade de um servidor de aplicativos para a versão 23.0 no Linux 6, vários patches não deverão ser aplicados ou o upgrade falhará durante o patch. "Rel_22.0/v1.450/ ". Não aplique esses patches ao AS ao atualizar para 23.0: AP.platform.23.0.1075.ap38541, AP.as.23.0.1075.ap385380, AP.as.23.0.1075.ap385413 e AP.as.23.0.1075.ap385453.

Revisar Documentação

As notas de versão da versão de destino e quaisquer versões entre a versão de origem e de destino devem ser revisadas. Se a versão de destino for 24.0, as notas de versão para 22.0, 23.0 e 24.0 deverão ser revisadas.
Notas da versão 23.0

Notas da versão 24.0
Método de Procedimento de Atualização
Consulte a Matriz de Compatibilidade de Software para obter os caminhos de atualização com suporte oficial.

Requisitos de licença

Uma nova licença é necessária para a versão de destino. Para solicitar uma licença, abra um tíquete. Para atualizações para 24.0, solicite que as licenças PS e XSP sejam convertidas em licenças ADP; o ADP não aceita uma licença PS ou XSP.

Alinhamento da RI com a versão principal

2018.xx = R22
2019.01 to 2020.06 = R23
2020.07 to 2022.07 = R24

Melhores práticas

Solicitar suporte

A equipe de atualização da BroadWorks disponibiliza suporte direto à atualização.

A equipe de atualização da BroadWorks fornece suporte para atualizações para uma versão atual "em suporte", para laboratório e produção, uma vez por ano sob o contrato de manutenção e suporte. A equipe de atualização pode fornecer suporte com a preparação para uma atualização e suporte em tempo real durante a atualização, que pode incluir engenheiros da Cisco que executam a atualização remotamente. O escopo da Equipe de Atualização é limitado apenas à atividade de atualização e não fornece suporte direto para problemas que precisam ser resolvidos antes da atualização, como atualizações de hardware ou do Sistema Operacional, ou depuração de problemas preexistentes e não fornece teste pós-atualização abrangente além de verificações gerais de integridade do servidor.

Entre em contato com a equipe de atualização da BroadWorks, através da equipe de contas, ou envie um e-mail para bwupgrade@cisco.com. A disponibilidade para suporte à atualização em tempo real não está disponível a curto prazo, com agendamento antecipado.

Notificar o suporte da BroadWorks antes de uma atualização

Se estiver executando uma atualização sem o suporte da Equipe de atualização, é recomendável notificar o Suporte da BroadWorks com alguns dias de antecedência com um tíquete de gravidade 4 (s4). Se surgir um problema durante a manutenção, aumente a gravidade do tíquete para s1, abra um novo tíquete s1 ou ligue para a linha de suporte para falar com um engenheiro.

Planos de teste

Um plano de teste é essencial para garantir uma atualização tranquila. Um plano de teste deve ser desenvolvido e testado em um laboratório antes de uma atualização de produção. Execute o plano de teste no sistema antes da atualização e registre os resultados. Isso garante que o sistema esteja íntegro, verifica se todos os usuários e contas de teste estão configurados e funcionando corretamente, oferece uma oportunidade para detectar possíveis lacunas no plano de teste e fornece uma estimativa de tempo sobre quanto tempo se espera que o teste dure.

Cada servidor deve ser testado após a atualização para garantir que esteja funcionando conforme esperado antes de passar para a atualização para o próximo servidor na sequência.

Patches

Corrija a versão de origem para 6 meses ou menos do nível de patch mais recente antes da atualização.

Script de verificação de pré-instalação

O script de verificação de pré-instalação deve ser executado em todos os servidores, laboratórios e produção e quaisquer avisos ou falhas solucionados antes da atualização.

Atualização de laboratório

É sempre recomendável testar o upgrade, o plano de teste e a versão de destino com quaisquer ferramentas, aplicativos ou clientes de terceiros em um ambiente de laboratório que replique o ambiente de produção. O laboratório pode ser reduzido, mas deve ter os mesmos tipos de servidor, versão de software, versão do SO, dispositivos de acesso, Session Border Control (SBC), etc. Trate a atualização do laboratório como uma simulação da atualização do ambiente de produção. Use o nível de patch da versão alvo mais recente ao atualizar o laboratório. Mantenha o tempo entre o laboratório e a atualização da produção em 3 meses ou menos. 

Sequência de Programação e Atualização

Espera-se que as atualizações ocorram em várias janelas de manutenção distribuídas por várias noites e são executadas na Ordem de instalação e atualização, conforme documentado na seção 4.2 do Guia de gerenciamento de software. Sempre execute atualizações durante uma janela de manutenção predeterminada (durante uma hora não ocupada). Sempre atualize um nó de cada vez e certifique-se de que um ou mais nós de um cluster estejam inativos a qualquer momento. O comprimento da janela de manutenção (MW), o número de servidores a serem atualizados, o tipo de servidor e o tempo que se espera que o teste leve determinam quantas janelas de manutenção são necessárias. Todos os servidores em um cluster devem ser atualizados na mesma MW. Deixe o tempo disponível na MW programada para solução de problemas e/ou reversão, se necessário.

Falhas de Atualização

Se for detectado um problema durante o teste pós-upgrade ou se houver falha em um upgrade, colete os logs antes de reverter para a versão de origem ou restaurar o servidor. Faça backup de todo o diretório de logs para garantir que todos os logs possivelmente úteis sejam mantidos. Abra imediatamente um tíquete e ligue para o Suporte para obter assistência enquanto estiver no MW.