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 24.0.
Overview
O BroadWorks Versão 24.0 suporta atualizações para versões 25.0 e 26.0. A Versão 24.0 Fim da Manutenção (EoM) foi anunciada para o final de julho de 2026. Todos os servidores atualizam para a versão independente de versão mais recente disponível (consulte a seção Matriz de compatibilidade de software intitulada 'Mapas de atualização suportados') até 2028.07.
Versões independentes de lançamento
Na versão 25.0, todos os servidores são independentes de versão. Todos os novos recursos, bugs e correções de segurança são fornecidos em uma nova versão. Patches não estão disponíveis, em vez disso, os servidores devem 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.
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 6 terminou em 30 de abril de 2023 com o 2023.05.
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 2023.09+.
Versões principais do Linux suportadas
R24 6,5+, 7, 8
R25 6,5+, 7, 8
Versões independentes de versão do 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
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. Atualizações de XSP devem ocorrer após o AS ser atualizado. 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 da Web e do Cisco BroadWorks devem ser atualizados manualmente no XSP, no PS e no ADP.
Ao atualizar servidores ADP para 2025.07 ou posterior, há uma alteração na versão do Java JRE que complica a atualização se os aplicativos independentes de versão e ancorados na versão estiverem misturados no servidor ADP. Consulte este documento de ajuda para obter mais informações.
DBS
O DBS é EoL (End of Life). 2024.09 é a versão final das aplicações DBS e ECCR. O ECCR deve ser substituído por CCER. Para obter mais informações sobre opções para o DBS, consulte este documento. Quando o ECCR não estiver mais em uso, o DBS deverá ser desativado.
Registros de chamadas avançados (ECL)
O 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.
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 25.0
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. Solicitar que as licenças PS e XSP sejam convertidas em licenças ADP; o ADP não aceita uma licença PS ou XSP.
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.
Patches
Corrija a versão de origem para seis 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 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 três 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.
Feedback