O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como substituir com segurança e confiabilidade os servidores Acano X-Series por máquinas virtuais (VMs) do Cisco Meeting Server (CMS), servidores CMS1000 ou CMS2000. O suporte aos servidores Acano X-Series foi removido da versão 3.0 em diante. O software mais recente que você pode executar em um X-Series é 2.9.5, que só é suportado até 1º de março de 2022. Depois disso, não haverá mais versões de manutenção ou correções de bugs. Isso significa que, se você tiver um servidor Acano X-Series, precisará planejar substituí-lo antes disso.
A Cisco recomenda que você tenha conhecimento destes tópicos:
As informações neste documento são baseadas nos servidores Cisco Meeting Server (VM ou CMS1K ou CMS2K) e Acano X-Series.
The information in this document was created from the devices in a specific lab environment. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Ao substituir os servidores X-Series, você precisa estar ciente das capacidades de chamadas dos vários servidores. Consulte os guias de implantação do Cisco Meeting Server, no Apêndice C (https://www.cisco.com/c/en/us/support/conferencing/meeting-server/products-installation-and-configuration-guides-list.html), para obter diretrizes de dimensionamento.
Tamanhos da série X para referência:
O processo de configuração do servidor de substituição pode ser encontrado na documentação de instalação e não é abordado abaixo. Os guias de instalação podem ser encontrados aqui: https://www.cisco.com/c/en/us/support/conferencing/meeting-server/products-installation-guides-list.html.
O método suportado para substituir os servidores X-Series é adicionar o novo dispositivo ao cluster de banco de dados para obter uma cópia do banco de dados.
Caution: Não use um backup de um servidor X-Series para implantar sua substituição.
Nem todas as etapas abaixo são necessárias para concluir a substituição. Coloque os novos servidores em cluster com os servidores antigos para que eles obtenham uma cópia do banco de dados é a parte mais importante.
Depois de concluir o processo de migração, todas as informações do banco de dados (regras de entrada, regras de saída, espaços, ids de chamada, etc.) também estarão nos novos servidores.
Note: Os dados inseridos na interface gráfica do usuário (GUI) em Configuration > General and Configuration > Ative Diretory NÃO estão no banco de dados. Você deve mover sua configuração LDAP (Lightweight Diretory Access Protocol) da GUI para a API (Application Programming Interface, Interface de programação de aplicativos). Se você ainda não estiver preparado para fazer isso, copie todos os dados dessas duas páginas para que eles possam ser inseridos novamente nos novos servidores. Lembre-se de que a senha para o nome de usuário LDAP também é necessária para o LDAP porque você não pode copiar essas informações.
Primeiro, você encontrará uma descrição de alto nível do fluxo de trabalho, seguida pela instrução passo a passo. É altamente recomendável seguir as instruções passo a passo para o procedimento de substituição.
Etapa 1. Crie arquivos de backup de antigos servidores Acano X-Series.
Etapa 2. Descarregue o arquivo de backup e o arquivo logbundle.tar.gz dos servidores antigos caso sejam necessárias informações para configurar o MMP (Mainboard Management Processor) do novo servidor.
Etapa 3. No seu antigo servidor X-Series, faça login no MMP, obtenha a saída de cada serviço/configuração e copie as informações em um arquivo de anotação.
Etapa 4. Configurar novos servidores.
Etapa 5. Obtenha licenças no(s) novo(s) servidor(es).
Etapa 6. Copiar certificados de servidores antigos para novos servidores.
Passo 7. Ative os serviços MMP nos novos servidores que foram configurados no servidor antigo.
(A Acano X-series pode usar uma interface Admin dedicada para gerenciamento. Você precisa gerenciar o novo servidor através da interface A-D, mas todos os serviços no novo servidor podem estar na interface A.)
Etapa 8. Crie as mesmas contas de usuário nos novos servidores que foram usados nos servidores antigos.
Etapa 9. Copie o banco de dados para os novos servidores.
Etapa 10. Remova o X-Series do cluster do banco de dados.
Etapa 11. Desligue o servidor X-Series que o novo servidor substitui.
Etapa 12. Altere o IP no novo dispositivo para corresponder à interface X-Series antiga A IP que está sendo substituída. Se você usa várias interfaces na série X, você deve usá-las nos novos servidores também porque isso elimina a necessidade de alterar qualquer registro DNS.
Etapa 13. Junte o servidor de volta ao cluster de banco de dados (somente se a implantação original não for um único servidor combinado).
Etapa 14. Ajuste os limites de carga de acordo com os novos servidores na API - api/v1/system/configuration/cluster.
Etapa 15. Teste a implantação para garantir que ela ainda funcione.
Etapa 1. Crie um backup usando o comando MMP backup snapshot <server_specific_filename>.
Etapa 2. Baixe o arquivo de backup e um arquivo logbundle.tar.gz (https://video.cisco.com/video/5810051601001) de cada um dos servidores X-Series que você deseja substituir.
Etapa 3. Execute os seguintes comandos nos servidores X-Series para obter a configuração dos vários serviços e colocá-los em um arquivo de anotação. Isso fornece uma referência fácil sobre como reconfigurar seus novos servidores.
'webadmin', 'callbridge', 'webbridge', 'xmpp', 'virar', 'dns', 'ntp server list', 'tls sip', 'tls ldap', 'tls dtls', 'tls webadmin', 'database cluster status', 'ipv4 a', 'ipv4 b', 'ipv4 c' , 'ipv4 d', 'ipv4 admin', 'gravador', 'otimizador', 'carregador', 'dscp', 'sipedge', 'h323_gateway', 'syslog', 'ldap'
Note: H323_gateway, Sip Edge e XMPP foram substituídos no CMS 3.0.
Se você usa o SIP Edge, é necessário ter um Cisco Expressway-C e E para rotear o tráfego de e para a Internet.
Se você usa o gateway H323, é necessário configurá-lo usando um servidor Cisco Expressway para executar o interfuncionamento de H.323 para SIP.
Se você usar o XMPP, ao atualizar para o CMS 3.x, precisará fazer algumas alterações de configuração. No entanto, se você estiver prestes a substituir a série X e permanecer no 2.9.x por um tempo, e precisar usar o WebRTC, o gravador ou o otimizador, será necessário reconfigurar o XMPP no novo servidor.
Você pode ler mais sobre as alterações a serem conhecidas antes da atualização para o CMS 3.0 neste documento.
Etapa 4. Configure os novos servidores. Certifique-se de que eles tenham a mesma versão de código que os servidores X-Series. Dê aos servidores IPs não usados para uso no momento (ipv4 <interface> add <address>/<prefix length> <gateway>), mas quando o trabalho é concluído, os IPs são alterados para o que foi usado na série X. Isso evita qualquer alteração nos registros e certificados DNS. Se não quiser reutilizar os IPs antigos, você deve atualizar o DNS e os certificados de acordo.
Etapa 5. No novo servidor e no antigo MMP do servidor X-Series, execute a interface de comando a fim de obter o endereço MAC das interfaces A. No X-Series que está prestes a ser substituído, faça o download do arquivo cms.lic e abra um caso de licenciamento do TAC. Forneça ao agente de licenciamento o endereço MAC A da interface do novo servidor e o MAC do servidor antigo e diga a ele que você deseja substituir o servidor antigo por um novo. Peça que troquem as licenças do MAC antigo pelo novo MAC. Um novo arquivo de licença é fornecido, que você precisa descompactar, renomear como cms.lic e carregar no novo servidor.
Etapa 6. Copie os certificados, chaves e arquivos da autoridade de certificação (CA) usados no antigo X-Series para o(s) novo(s) servidor(es) usando WinSCP ou qualquer outro programa SFTP.
Passo 7. No novo servidor, ative os mesmos serviços e configurações no MMP que você tem atualmente em seu antigo X-Series. Consulte as informações reunidas na Etapa 3 para garantir que você faça as mesmas configurações de antes.
Note: Se você for atualizar para o CMS 3.x imediatamente após a configuração desses novos servidores, não precisará configurar os componentes XMPP, Webbridge, SIP Edge ou H323_gateway. Eles não são mais usados no CMS 3.x.
Etapa 8. Crie as mesmas contas de usuário que estavam nos servidores X-Series no MMP usando o comando user add <username> <role> (assim como user rule <rule name> <value> se você tiver alguma regra configurada). Outros dispositivos como Cisco Meeting Management (CMM), TelePresence Management Suite (TMS) ou Cisco Unified Communications Manager (CUCM) podem ser configurados para recursos com essas contas, portanto, você precisa garantir que os configure nos novos servidores.
Etapa 9. Obtenha uma cópia do banco de dados para o(s) novo(s) servidor(es).
9a. Se a implantação atual for um único servidor combinado (sem cluster de banco de dados), você precisará inicializar um cluster de banco de dados nele. A partir da versão 2.7 do CMS, um cluster de banco de dados requer certificados. Portanto, uma autoridade de certificação integrada foi introduzida no CMS a partir da versão 2.7 que você pode usar para assinar certificados de banco de dados:
1. No único MMP da série X combinado, execute pki selfsigned dbca CN:<Company Name> (ex. pki selfsigned dbca CN:tplab.local)
2. No único MMP da série X combinado, crie um certificado para o servidor de banco de dados com pki csr dbserver CN:xseries.example.com subjectAltName:<newcms1fqdn>
(Não é necessário ter registros DNS A neste ponto.)
3. No único MMP combinado X-Series, crie um certificado para o cliente de banco de dados com pki csr dbclient CN:postgres
4. No único MMP da série X combinado, use dbca (da Etapa 1) para assinar o certificado dbserver (da Etapa 2) pki sign dbserver dbca
5. No único MMP da série X combinado, use dbca (da Etapa 1) para assinar o certificado dbclient (da Etapa 3) pki sign dbclient dbca
6. Copie os arquivos dbserver.crt, dbserver.key, dbclient.crt e dbclient.key para todos os servidores que serão associados ao banco de dados (nós que formam o cluster de banco de dados) do X-Series para os novos servidores
7. Copie o arquivo dbca.crt para todos os servidores da série X
8. No único MMP da série X combinado, execute database cluster certs dbserver.key dbserver.crt dbclient.key dbclient.crt dbca.crt (dbca.crt como certificado CA raiz)
9. No único MMP da série X combinado, execute o cluster de banco de dados localnode a
10. No único MMP da série X combinado, execute o cluster de banco de dados inicialize
11. No único MMP da série X combinado, execute o status do cluster do banco de dados. Você deve ver:
Nós: <XseriesIP> (me): Primário conectado
12. No(s) novo(s) servidor(es) ao qual você ingressará no cluster do banco de dados, execute o banco de dados certs dbserver.key dbserver.crt dbclient.key dbclient.crt dbca.crt
13. No(s) novo(s) servidor(es) ao qual você irá se juntar (co-localizado com um banco de dados), no MMP:
a. executar nó local de cluster de banco de dados a
b. executar associação de cluster de banco de dados <IP de nó primário>
Neste ponto, o(s) novo(s) servidor(es) tem(têm) uma cópia do banco de dados. Execute o status do cluster de banco de dados no MMP no novo servidor para garantir que eles sejam exibidos como em sincronização. Se estiverem, você terminará com a Etapa 9 e poderá continuar com a Etapa 10. No entanto, se eles não estiverem em sincronia, você deve revisar suas configurações de cluster de banco de dados e garantir que não haja nada na rede que bloqueie a comunicação sobre o TCP 5432 entre os servidores.
9 ter. Se a implantação atual já for um cluster de banco de dados, substitua os servidores X-Series um de cada vez. No X-Series, execute o status do cluster de banco de dados MMP para verificar se o servidor está conectado ao cluster de banco de dados ou conectado. Se o IP do servidor estiver na lista de clusters do banco de dados, ele será associado. Se não estiver, e o último comando mostrado for 'database cluster connect', o nó está conectado.
Você deseja adicionar o novo nó de volta como a mesma função (associado ou conectado), portanto, anote qual a função do servidor X-Series. Se o X-Series for o banco de dados principal, reinicialize o servidor primeiro para que ele se torne uma réplica.
1. Na série X que está prestes a ser substituída, anote os certificados usados para chaves/certificados de servidor, chaves/certificados de cliente e certificados CA
2. No X-Series que está prestes a ser substituído, execute o cluster de banco de dados remova
Etapa 10. Se você substituir um único servidor combinado X-Series, continue aqui com a Etapa 10. Se for um cluster, vá para a Etapa 11.
Neste ponto, o novo servidor tem uma cópia do banco de dados. Você pode confirmar isso com um login na interface da Web do novo servidor e verificar a configuração de usuários e espaços. Após a confirmação, remova o novo servidor do cluster de banco de dados e altere os IPs:
1. No novo servidor, execute 'cluster de banco de dados removido'.
2. Desligue o servidor X-Series.
3. Altere os IPs do novo servidor para os usados no servidor X-Series.
4. Reinicie o novo servidor.
5. Se você ficar na versão CMS 2.9.x, teste o novo servidor para garantir que todas as configurações funcionem.
6. Faça login na página do administrador da Web do novo servidor e veja os espaços e os usuários. Você deve ver todos os espaços e usuários que estavam anteriormente no servidor quando ingressaram no banco de dados mais cedo, pois ele pegou uma cópia disso.
Etapa 11. Se você substituir um servidor X-Series que faz parte de um cluster, poderá seguir as próximas etapas:
1. Desligue o servidor X-Series que planejamos desativar.
2. Altere os IPs no novo servidor para o que foi usado anteriormente na interface de nó local do banco de dados do servidor X-Series (tipicamente a).
3. Copie a chave/certificado do servidor, a chave/certificado do cliente e o certificado CA para o novo servidor com um programa SFTP.
4. No novo servidor, execute o comando: 'database cluster localnode a'
5 bis. Se o novo nó for associado ao cluster do banco de dados, execute o comando ‘database cluster certs <server.key> <server.crt> <client.key> <client.crt> <ca.crt>'
5 ter. Se o novo nó for conectado (não co-localizado com um banco de dados) ao cluster do banco de dados, execute o comando 'database cluster certs <client.key> <client.crt> <ca.crt>'.
6 bis. Se o novo nó precisar ser associado (co-localizado com um banco de dados), execute o comando: 'associação de cluster de banco de dados <IP de nó primário>'
6 ter. Se o novo nó precisar ser conectado (não co-localizado com um banco de dados), execute o comando:'database cluster connect <primary node IP>'
Repita as etapas 9b e 11 para cada X-series que você precisa desativar.
Etapa 12. Neste ponto, os novos servidores CMS terão uma cópia do banco de dados ou, se conectados, saberão como alcançar os nós do banco de dados e terão os mesmos endereços IP que antes também.
Etapa 13. O balanceamento de carga está habilitado na implantação?
Se você usar o balanceamento de carga de chamadas do CMS com CallBridgeGroups na API configurada com Loadbalance=True, você deverá alterar o limite de carga para corresponder aos limites recomendados dos novos servidores no ambiente. Vá para api/v1/system/configuration/cluster e atualize o limite de carga de acordo:
Sistema | Limite de carga recomendado |
CMS1000 M5v2 | 120000 |
CMS1000 M4 ou M5v1 | 96000 |
CMS2000 M5v2 | 875000 |
CMS2000 | 700000 |
VM (número de vCPU x 1250) | exemplo: 70 vCPU x 1250 = 87500 |
Etapa 14. Se você tiver um cluster XMPP antes desse trabalho e quiser ficar no CMS 2.9.x por um tempo, precisará reconstruir seu cluster XMPP.
Comandos MMP |
Examples |
Configurar todos os nós XMPP |
Configurar todos os nós XMPP |
1. xmpp reset |
1. xmpp reset |
2. xmpp domain <nome do domínio> |
2. xmpp domain example.com |
3. xmpp Listen <interface whitelist> |
3. xmpp Listen a |
4. xmpp certs <keyfile> <certificate file> <cert-bundle> |
4. xmpp certs xmppcluster.key xmppcluster.cer root.cer |
5. xmpp cluster trust <xmpp cert> |
5. xmpp cluster trust xmppcluster.cer *** Nota 1 |
Configuração do 1º nó |
Configuração do 1º nó |
6. xmpp enable |
6 xmpp enable |
7. xmpp callbridge add <callbridge name> |
7. xmpp callbridge add cb1 |
8. xmpp callbridge add <callbridge name> |
8. xmpp callbridge add cb2 |
9. xmpp callbridge add <callbridge name> |
9. xmpp callbridge add cb3 |
10. xmpp callbridge add <callbridge name> |
10. xmpp callbridge add cb4 *** Nota 2 |
11. xmpp callbridge list |
11. xmpp callbridge list <— copie esta saída no notepad |
12. xmpp disable |
12. xmpp disable |
13. xmpp cluster enable |
13. xmpp cluster enable |
14. xmpp cluster initialize |
14. xmpp cluster initialize |
15. xmpp enable |
15. xmpp enable |
16. status de cluster xmpp |
16. status de cluster xmpp |
Configuração do 2º e 3º nó |
Configuração do 2º e 3º nó |
17. xmpp enable |
17. xmpp enable |
18. xmpp callbridge add-secret <callbridge name> |
18. xmpp callbridge add-secret cb1 |
19. insira o segredo da callbridge: |
19. Insira o segredo da callbridge: <copy secret para cb1 do notepad> |
20. xmpp callbridge add-secret <callbridge name> |
20. xmpp callbridge add-secret cb2 |
21. Insira o segredo da callbridge: |
21. Insira o segredo da callbridge: <copy secret para cb2 do bloco de notas> |
22. xmpp callbridge add-secret <callbridge name> |
22. xmpp callbridge add-secret cb3 |
23. Insira o segredo da callbridge: |
23 : Insira o segredo da callbridge: <copy secret para cb3 do notepad> |
24. xmpp callbridge add-secret <callbridge name> |
24. xmpp callbridge add-secret cb4 *** Nota 3 |
25. Insira o segredo da callbridge: |
25. Insira o segredo da callbridge: <copy secret para cb4 do notepad> |
26. xmpp disable |
26. xmpp disable |
27. xmpp cluster enable |
27. xmpp cluster enable |
28. xmpp enable |
28. xmpp enable |
29. xmpp cluster join <cluster> |
29. xmpp cluster join <endereço IP ou FQDN do Nó 1> |
Configurar as definições XMPP no Web Admin |
Configurar as definições XMPP no Web Admin |
Em cada servidor com o serviço CallBridge |
Em cada servidor com o serviço CallBridge |
30. Insira este nome exclusivo das callbridges configurado acima |
30. Digite cb1 no callbridge1, etc |
31. Insira o domínio |
31. Insira o domínio: example.com |
32. Insira o segredo do bloco de notas |
32. Insira o segredo do bloco de notas para o callbridge correspondente |
33. Verificar a página de status do webadmin para autenticação |
33. Verificar a página de status do webadmin para autenticação |
Nota 1: xmpp cluster trust no exemplo é o certificado XMPP porque o certificado contém todos os FQDNs do servidor XMPP no atributo Subject Alternative Name (SAN) ou é um certificado curinga. Se cada servidor XMPP tiver seu próprio certificado, você precisará combiná-los e adicioná-los como a confiança do cluster xmpp.
Nota 2: xmpp callbridge add cb4. Adicionada esta etapa como um exemplo de que você pode ter mais callbridges do que os servidores xmpp. Essa etapa não é necessária, mas foi adicionada como exemplo.
Nota 3: xmpp callbridge ad-secret cb4. Adicionada esta etapa para acompanhar a Nota 2. Se você tiver 4 callbridges, será necessário adicionar todos os 4 nós no cluster xmpp.
Se você ficar na versão CMS 2.9.x, poderá começar os testes e a validação agora para garantir que os novos servidores funcionem conforme esperado.
Após a migração para o(s) novo(s) servidor(es), verifique se todos os seus usuários e espaços estão visíveis e se suas chamadas SIP ainda funcionam. Se você continuar na versão CMS 2.9.x, confirme se o XMPP ainda funciona (os usuários do WebRTC ainda podem se conectar/entrar, o gravador pode se conectar, etc.). Verifique os servidores que estão em comunicação com o CMS para garantir que ainda estejam funcionando (Cisco Meeting Manager (CMM), Cisco Unified Communications Manager (CUCM), TelePresence Management Suite (TMS), Expressway). Também é uma boa ideia executar o 'syslog siga' no MMP para ver se há erros que precisam ser solucionados.
Se você tiver problemas, poderá voltar para os servidores X-Series ou entrar em contato com o Cisco TAC para obter suporte.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
23-Aug-2021 |
Versão inicial |