Guia para atualização do BroadWorks 23.0

Introdução

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

Overview

O BroadWorks Versão 23.0 suporta atualizações para versões 24.0 e 25.0. A Versão 23.0 era EoM no final de julho de 2024, e a 24.0 Fim da Manutenção (EoM) é esperada no final de julho de 2026. Servidores não-aplicativos 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'). Os servidores de aplicativos são atualizados para 2024.07. Quando todos os servidores forem atualizados, os Servidores de Aplicativos deverão ser atualizados novamente para a versão mais recente, até 2026.07.

Versões independentes de lançamento

A partir da versão 23.0, o MS é Release Independent (RI), na versão 24.0, todos os servidores, exceto o Application Servers (AS) RI, e na versão 25.0, todos os servidores são Release Independent. 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.

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 quatro dígitos
• mm é o mês de dois 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 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

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.10+: 7, 8, 9 (Linux 9 não é suportado no AS até 2024.04)

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

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

2018.11 a 2020.08: 6,5+, 7
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 é executar 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. Ao atualizar da versão 23.0, o PS e o XSP só podem atualizar até a versão 2024.07 do ADP. Depois disso, o ADP deverá ser atualizado novamente para obter a versão mais recente.

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 da Web e do Cisco BroadWorks devem ser atualizados manualmente no XSP, no PS e no 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 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. Versões RI 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 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 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) 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 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 em 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. Se a versão de destino for 24.0, as notas de versão para 24.0 e 25.0 devem ser revisadas.
Notas da versão 24.0

Notas da versão 25.0 e superiores
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. 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

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 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.

Histórico de revisões

Revisão	Data de publicação	Comentários
1.0	06-Aug-2026	Versão inicial