Guia para atualização do BroadWorks 25.0

Introdução

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

Overview

Todos os servidores atualizam para a versão independente mais recente disponível (consulte a seção Matriz de compatibilidade de software intitulada 'Mapas de atualização suportados').

Requisitos do sistema operacional

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

Os sistemas operacionais suportados são Red Hat Enterprise Linux, Oracle Linux e CentOS 7. CentOS 8, CentOS Stream, Rocky Linux e Alma Linux não são suportados.

O suporte ao Linux 7 terminou em 20 de junho de 2024 com 2024.07.

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

Versões Linux suportadas

2020,07+: 6,5+, 7, 8
2023,05+: 7, 8

2023.10+: 7, 8, 9 (o Linux 9 não é suportado nos servidores de aplicativos (AS) até 2024.04)

2024,04+: 7, 8, 9
2024,07+: 8, 9

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

2020.11 a 2022.06: Somente 7.5+
2022,07+: 7,5+, 8,5+

2024,07+: 8,5+

2024.09 : Versão final/Fim da vida útil

Atualizações do SO

Historicamente, a BroadWorks não oferece suporte a upgrades no local entre as principais versões do Linux. Historicamente, a recomendação era realizar uma troca de hardware, criar um novo servidor na versão Linux de destino e migrar o servidor existente para o novo servidor. A partir da versão 2023.12, os upgrades Linux in-loco são suportados do Linux 7 para 8 e 8 para 9. Para executar um upgrade Linux in-loco, os servidores devem primeiro ser atualizados para 2023.12 ou posterior.

Para obter a documentação sobre atualizações do Linux no local, consulte a seção 9 do Guia de gerenciamento de software. Para obter a documentação sobre o processo de troca de hardware, consulte seção 5.2.6 do Guia de gerenciamento de software e seção 12.2 do Guia de manutenção.

Não é recomendável usar uma troca de hardware para atualizar o BroadWorks ao mesmo tempo ou para executar uma troca de hardware ou uma atualização Linux no local e uma atualização do 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

DBS

O 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 oferece suporte ao Linux 5 e 6. Se estiver executando o Linux 5, o DBS não poderá fazer upgrade além do 22.0. As versões independentes do DBS não oferecem suporte ao Linux 5. Se estiver executando o Linux 6, o DBS poderá fazer upgrade para o 2020.08. O DBS deverá, então, fazer a troca de hardware para o Linux 7, onde poderá fazer upgrade novamente. Ao atualizar o DBS e o Servidor de Perfil (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
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 banco de dados (DB) da versão 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) está no 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 22.0. O UMS no 22.0 usa o MariaDB em vez do Oracle TimesTen, necessitando de etapas adicionais para fazer o upgrade, tem um MoP (Método de Procedimento) 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.

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.

Notas da versão 26.0
Método de Procedimento de Atualização (MOP)
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.

Melhores práticas

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

Recomenda-se notificar o BroadWorks Support 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.

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

O script de verificação de pré-instalação deve ser executado em cada servidor, laboratório e produção, e quaisquer avisos ou falhas devem ser 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 executar atualizações durante uma janela de manutenção predeterminada (durante uma hora não ocupada). Sempre atualizar um nó por vez e garantir que um ou mais de um nó de um cluster esteja inativo 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.

Histórico de revisões

Revisão	Data de publicação	Comentários
1.0	19-May-2026	Versão inicial