Configurar orquestração para UCCE

Introdução

Este documento descreve as etapas para configurar o Contact Center Enterprise Orchestration.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Unified Contact Center Enterprise (UCCE) 12.x
• Packaged Contact Center Enterprise (PCCE) 12.x
• Cisco Voice Portal (CVP) 12.x
• Finesse 12.x
• Cisco Unified Intelligence Center (CUIC) 12.x
• Virtual Voice Browser (VVB) 12.x

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software:

• Cloud Connect 12.6(1) ES3
• UCCE 12.5(1)
• Finesse 12.5(1)
• CUIC 12.5(1)
• CVP 12.5(1)
• VVB 12.5(1)

Observação: em todo o documento, o CUIC se refere às instalações co-residentes e às instalações autônomas do CUIC, Live Data (LD) e Identity Server (IDS). Somente quando uma instrução é específica para um subcomponente, esse componente é referenciado.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Requisitos de versão

UCCE/PCCE 12.5(1) (ambos)

• ES66 (ES55 é uma instalação obrigatória antes da instalação do ES66)
• UCCE 12.5(2) MR

UCCE/PCCE 12.6(1)

• Sem requisitos adicionais

Cloud Connect Versão: 12.6(1)

• ES3 

Finesse, CUIC, VVB: 12.5(1)

• ucos.orchestration.enable-12.5.1.cop.sgn
• ucos.keymanagement.cop.sgn

Finesse, CUIC, VVB: 12.6(1)

• ucos.keymanagement.cop.sgn

CVP 12.5(1)

• ES23

CVP 12.6(1)

• Sem requisitos adicionais

Observações especiais para atualizações do Cloud Connect.

Observação: quando você atualiza o Cloud Connect de 12.5 para 12.6, é obrigatório instalar ucos.keymanagement.cop.sgn primeiro. A atualização falha se isso não for feito.

Observação: quando você atualiza o Cloud Connect de 12.5 para 12.6, é obrigatório aumentar o disco de 146 GB para 246 GB. Se essa etapa tiver sido perdida antes da atualização, execute estas etapas:
Etapa 1: Pare o servidor do Cloud Connect.
Etapa 2: Expanda o disco no vSphere para 246 GB.
Etapa 3: Inicie o servidor Cloud Connect.
O VOS expande as partições automaticamente. Isso garante que as atualizações baixadas não causem uma condição de falta de espaço na partição comum.

Overview

A orquestração do CCE é suportada a partir do Cloud Connect 12.6(1).

A versão 12.6 (1) do servidor do Cloud Connect suporta orquestração nestes cenários:

• As atualizações do CCE 12.5 ES/COP e do Windows podem ser orquestradas a partir do servidor 12.6 Cloud Connect
• A atualização do software CCE 12.5 para 12.6 pode ser orquestrada a partir do servidor 12.6 Cloud Connect

Etapas de instalação e configuração

Etapa 1. Gerar a Chave API Artefativa

1. Faça login em https://devhub-download.cisco.com/console/ com seu nome de usuário e senha do CCO.
2. Selecione Gerenciar chave de download na página do console conforme mostrado na imagem.
   
3. Clique na opção Gerar chave para gerar a chave de API. A opção View and Revoke Key está disponível na página Manage Download Key.
   
4. Selecione o botão Copiar para copiar a chave de API para a área de transferência.

Observação: é obrigatório que a ID do CCO usada para gerar chaves de API tenha as qualificações de atualização de software necessárias. A ID do CCO que você usa deve ter um SWSS (contrato de serviço) ou assinatura Flex válido para ter a qualificação necessária.

Observação: você deve fazer login em https://devhub-download.cisco.com/console uma vez a cada seis meses para estender a validade da chave de API.

Etapa 2. Configurar a URL Artefativa e a Chave de API no Cloud Connect

• A Cisco hospeda todos os artefatos de software em um artefato baseado em nuvem que é usado pelo servidor Cloud Connect para baixar e notificar novas atualizações.
• O servidor Cloud Connect deve ser configurado com o software hospedado da Cisco Artifatory URL, Repository Name e API Key.

1. Execute o comando, utils image-repository set para configurar o download artificial como mostrado na imagem. 

a. Forneça o URL do artefato, https://devhub-download.cisco.com/binaries.

b. Forneça o nome do repositório artificial, net-platform-release-external.

c. Cole a chave de API gerada. A chave de API é mostrada como asteriscos por motivos de segurança.

2. Execute o comando utils image-repository show para exibir a URL do Artifatory, o Nome do Repositório e a Chave de API no servidor do Cloud Connect como mostrado na imagem.

Observação: antes que o comando utils image-repository set seja executado na CLI, navegue para o URL do EULA (https://software.cisco.com/download/eula) e aceite o EULA. Se isso não for feito, o comando utils image-repository set falhará com erro: a ID do CCO usada para gerar a chave da API não é compatível com o Contrato de licença do usuário final, use uma ID do CCO válida.
Consulte o bug da Cisco ID CSCvy78680 para obter mais informações.

Observação: esses dois comandos podem ser executados somente no nó do editor do servidor do Cloud Connect.
A replicação da configuração do repositório de imagens ocorre automaticamente do nó do editor para o nó do assinante quando o comando utils image-repository set é executado com resultados bem-sucedidos no nó do editor.

Observação: a CLI do conjunto de repositórios de imagens de utils pode ser usada a qualquer momento para alterar a opção de software export restricted vs unrestricted na implantação.
Reinicie o servidor do Cloud Connect para aplicar a limpeza e o download de software restrito versus irrestrito. O download é iniciado 10 minutos após a reinicialização.

Nota: Notas sobre operações artesanais:
Após a configuração bem-sucedida dos detalhes do artefato, os artefatos são baixados localmente no servidor do Cloud Connect às 02:00 da manhã, hora do servidor.
As operações de orquestração, como instalação de patch, reversão ou atualização, podem ser executadas somente após o download dos artefatos.
Se os artefatos precisarem ser baixados imediatamente após as etapas de configuração, o servidor do Cloud Connect poderá ser reiniciado e o download começará 10 minutos após a reinicialização.
O uso de comandos CLI relacionados à orquestração é bloqueado quando o download é iniciado e essa duração depende do número de artefatos a serem baixados.

Observação: se o servidor do Cloud Connect exigir um proxy para acessar a Internet, o ES3 ou superior deverá estar instalado. Consulte o Guia de instalação e atualização do UCCE para obter detalhes sobre a configuração do proxy.

Etapa 3. Nós VOS integrados ao nó de controle de orquestração

Pré-requisitos:

• Verifique se todos os requisitos de versão do sistema foram atendidos.
• Importe os certificados do cluster do Cloud Connect (Pub e Sub) para o tomcat-trust em todos os servidores VOS de destino (tomcat para autoassinado e root/intermediate para CA-signed)

Para integrar cada sistema Finesse, CUIC, VB, IDS, LD a um servidor Cloud Connect, execute o comando, utils system onboard initiate do nó do editor do respectivo cluster VOS, como mostrado na imagem. 

1. Forneça o FQDN do nó do editor do Cloud Connect.

2. Forneça o nome de usuário do aplicativo para o servidor do Cloud Connect.

3. Forneça a senha de usuário do aplicativo para o servidor do Cloud Connect.

• O nó do editor do servidor do Cloud Connect deve estar online quando o início onboard for executado do nó VOS.
• Quando o início onboard é executado a partir do nó VOS, o FQDN do servidor do editor do Cloud Connect deve ser usado.
• O comando utils system onboard initiate deve ser executado em todos os VOS Publishers (Finesse, CUIC, LD, IdS, todos VVBs)

Observação: se o sistema (cluster) se conectar ao servidor do Cloud Connect com erro parcial, verifique o motivo do erro e corrija-o. Em seguida, execute o comando utils system onboard update em vez do comando utils system onboard initiate.

Observação: a integração é permitida apenas quando os nós do editor e do assinante no servidor do Cloud Connect estão acessíveis.

Observação: se o servidor Cloud Connect for corrompido e reimplantado com uma instalação nova, o administrador terá que executar utils system onboard remove do nó VOS e, em seguida, executar utils system onboard initiate para integrar os nós VOS novamente.

Observação: para verificar/localizar o nome de usuário do aplicativo Servidores do Cloud Connect, execute o comando run sql select * from applicationuser na CLI dos Servidores do Cloud Connect.

Etapa 4: Onboard Windows Nodes to Orchestration Control Node

O processo integrado ajuda a estabelecer uma conexão sem senha entre o nó do Cloud Connect e os nós do Windows. Para integrar os nós baseados no Windows ao nó de controle de orquestração, execute estas etapas:

Configure a chave pública SSH nos nós do Windows:

a. Navegue até %Users%\<logonUser>\.ssh\ e crie o arquivo authorized_keys, se ele não existir. (O tipo de extensão authorized_keys é Arquivo e não pode ser modificado)

Observação: o usuário não deve ser removido do sistema e deve ser um usuário de domínio com privilégios de administrador de domínio ou de administração local.

b. Abra o navegador e insira o URL do editor do Cloud Connect: https://<CloudConnectIP>:8445/inventory/controlnode/key

c. Forneça suas credenciais de usuário do aplicativo Cloud Connect. Após a autenticação bem-sucedida, uma resposta da API REST busca a chave SSH pública do Cloud Connect.

d. Copie esse valor de chave pública no arquivo authorized_keys em %Users%\<logonUser>\.ssh\.

Um exemplo da saída do URL é mostrado. Na saída, copie somente a parte que começa com ssh-rsa e termina com root@localhost no arquivo authorized_keys.

{"category":"PUBLISHER","hostName":"cc125clouda.uclabservices.com","publicKey":"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDfJDl7RUZ/Umdflp5r3IqMaoV8WSrr7iLBOWindC0lGeGPYkprVW2xq6H6I8FuEjnBkrfEe8DUahVDVe783lFTb9nGdgRxAF7LR1MpKFOqOV9WRY8btYwRb0ZViO/GDupB2jBNaAj4M2EPPkKoC5OhcZrZ+4Zry/GEMd9uVwziyOh/nBxGuqg28euMiU2+G7m3qE3wo4zoJlvyOHkoM4tKzpiqqn0VdIRQ5xPhOl771AW6Rsiq4naG0f/hmVF347goavmF0O0lf1CbF4RfMoO1zxxlj+zi7RE1jl9aRMtzRmZC4uyIIQFtrZBbBbkzbk8dJo1u9A7Ds1rUcdEuc0Vv root@localhost"}

O arquivo authorized_keys do exemplo é mostrado.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDfJDl7RUZ/Umdflp5r3IqMaoV8WSrr7iLBOWindC0lGeGPYkprVW2xq6H6I8FuEjnBkrfEe8DUahVDVe783lFTb9nGdgRxAF7LR1MpKFOqOV9WRY8btYwRb0ZViO/GDupB2jBNaAj4M2EPPkKoC5OhcZrZ+4Zry/GEMd9uVwziyOh/nBxGuqg28euMiU2+G7m3qE3wo4zoJlvyOHkoM4tKzpiqqn0VdIRQ5xPhOl771AW6Rsiq4naG0f/hmVF347goavmF0O0lf1CbF4RfMoO1zxxlj+zi7RE1jl9aRMtzRmZC4uyIIQFtrZBbBbkzbk8dJo1u9A7Ds1rUcdEuc0Vv root@localhost

e. Repita as etapas b, c e d para buscar a chave pública do assinante do Cloud Connect (se o Cloud Connect for configuração de HA).

Observação: as chaves públicas do editor e do assinante do Cloud Connect devem ser copiadas em um único arquivo authorized_keys. As entradas do editor e do assinante devem estar em linhas separadas e não devem usar nenhum espaço extra, vírgula ou caracteres especiais no final da linha.

f. Reinicie os serviços OpenSSH:
- OpenSSH SSH Server
- Agente de autenticação OpenSSH

Solucione os problemas de login do SSH com estas etapas:

a. Navegue até C:\ProgramData\ssh e abra o arquivo sshd_config em um editor de texto.

b. Localize a seção deste arquivo que inicia o # Logging

c. Remova os comentários das linhas SyslogFacility e LogLevel.

d. Altere SyslogFacility para LOCAL0 e LogLevel para DEBUG, conforme mostrado no exemplo

# Logging
SyslogFacility LOCAL0
LogLevel DEBUG

e. Salve o arquivo sshd_config e reinicie o serviço OpenSSH SSH Server. 

f. O arquivo de log é gravado em C:\ProgramData\ssh\logs\sshd.log

Etapa 5: Atualize o arquivo inventory.conf

1. Execute o comando utils system inventory export para fazer o upload do inventário para um servidor SFTP conforme mostrado na imagem. 

a. Forneça o endereço IP ou FQDN de um servidor SFTP. 

b. Forneça o nome de usuário que tem acesso de leitura/gravação ao servidor SFTP.

c. Forneça a senha para o usuário.

d. Forneça o diretório para gravar o arquivo de inventário no formato UNIX/Linux. 

Exemplo: /voice/ipcc/Enterprise/Orchestration

2. Edite o inventário para incluir os componentes do VOS e do Windows.

• A sintaxe, o alinhamento e o recuo devem ser exatamente iguais aos do arquivo de inventário.
• As terminações de linha CRLF devem ser do estilo UNIX. Assim, um editor baseado em Linux ou em Mac OS pode ser usado para criar o arquivo de inventário do Windows. Um programa como o Notepad++ também pode ser usado.
• Os nomes dos componentes, como CVPREPORTING, ROGGER, PG e assim por diante, devem estar em letras maiúsculas.

Observação: o arquivo inventory.conf é sensível a recuos, consulte/use imagens e exemplos de arquivos de configuração

Arquivos de exemplo que mostram o formato correto podem ser baixados aqui: https://github.com/CXCCSummit/Repository

O exemplo do servidor VOS é mostrado na imagem:

O exemplo do Windows Server é mostrado na imagem:

3. Edite as strings no arquivo de inventário, conforme necessário.

deploymentName: forneça um nome exclusivo para a implantação.

• Esse nome aparece na linha de assunto da notificação por e-mail. Se não estiver configurado, a linha de assunto da notificação por e-mail conterá apenas o tipo de procedimento e o status geral.

deploymentType: este campo é usado para verificação de compatibilidade nos procedimentos de atualização, reversão ou encaminhamento de switch.

Os tipos de implantação suportados são:

• UCCE-2000-Agentes
• UCCE-4000-Agentes

• PCCE-2000-Agentes
• PCCE-4000-Agentes

• HCS-CC-2000-Agentes
• HCS-CC-4000-Agentes

Observação: revise essas observações sobre os tipos de implantação suportados.
A orquestração não é suportada para modelos de implantação de agentes 12000, 24000 e 26000.
No momento, o modelo de implantação HCS-SCC (Small Contact Center) não é compatível com Orchestration.
Certifique-se de que os valores inseridos neste campo estejam de acordo com o formato da lista de tipos de implantação suportados. O tipo de implantação diferencia maiúsculas de minúsculas.

Observação: O administrador pode atualizar ou editar os valores default, se necessário, com base no tipo de disponibilização e no nome da disponibilização preferencial.

4. Execute o comando utils system inventory import no nó do editor do Cloud Connect para importar o inventário atualizado do servidor SFTP, como mostrado na imagem.

a. Forneça o endereço IP ou FQDN de um servidor SFTP. 

b. Forneça o nome de usuário que tem acesso de leitura/gravação ao servidor SFTP.

c. Forneça a senha para o usuário.

d. Forneça o diretório para gravar o arquivo de inventário no formato UNIX/Linux. 

   Exemplo: /voice/ipcc/Enterprise/Orchestration

e. Responda 'sim' para permitir que o novo arquivo de inventário substitua o inventário atual.

Etapa 6: Validar nós integrados para orquestração

Para validar se os nós do VOS e do Windows foram integrados com êxito e para verificar se o recurso Orchestration está pronto para ser usado, execute o comando utils deployment test-connection, conforme mostrado na imagem.

Troubleshooting

Logs de orquestração em RTMT

Para baixar o RTMT do Cloud Connect, acesse https://FQDN:8443/plugins/CcmServRtmtPlugin.exe.

Você também pode exibir os logs mencionados abaixo usando a Real-Time Monitoring Tool (RTMT):

Logs de orquestração via CLI

Logs de auditoria
A avaliação de auditoria para a operação administrativa que é iniciada a partir da CLI do Orchestration no Cloud Connect é capturada nos registros de auditoria do Orchestration.
A tentativa de auditoria captura os detalhes de usuário, ação e data/hora da operação da CLI.

• arquivo get ativelog orchestration-audit/audit.log*

Logs CLI

• file get ativelog platform/log/cli*.log

Logs Ansible
Um log ansível, gerado durante a execução da CLI de instalação de ms-patches do gerenciador de patches do utils, captura os detalhes das atualizações do Windows, junto com o número da Base de conhecimento (KB) das atualizações que foram instaladas no nó de destino.

• Registros de transações atuais: arquivo get ativelog ansible/ansible.log
• Logs históricos: arquivo obter registro ativo ansible/ansible_history.log

Logs de Sincronização de Alta Disponibilidade de Status da Operação

• arquivo get ativelog ansible/sync_ansible_log_to_remote_cc.log

Logs relacionados a notificações por e-mail

• Registros de transações atuais:arquivo get ativelog ansible/ansible_email_cron.log

Logs de download de software

• Registros de transações atuais: arquivo get ativelog ansible/software_download_ansible.log
• Logs históricos: arquivo obter registro ativo ansible/software_download_ansible_history.log
• Logs de processo: arquivo get ativelog ansible/software_download_process.log

Listar os arquivos de log nos respectivos diretórios

• detalhes do ativeLog ansible/* da lista de arquivos
  file list ativelog platform/log/cli*.log detail