Perguntas frequentes sobre Automation Anywhere Enterprise Knowledge On-Premises

Consulte estas perguntas frequentes para ver perguntas comuns e respostas detalhadas sobre a implantação On-Premises da plataforma Automation Anywhere Enterprise Knowledge, abrangendo desde a definição e arquitetura de On-Premises até requisitos de infraestrutura, processos de implantação, considerações de segurança e mais.

Implantação

A instalação do Enterprise Knowledge On-Premises oferecerá suporte à instalação no AWS, GCP, Azure ou em bare metal e máquinas virtuais como VMWare?

Sim, temos as especificações necessárias para os ambientes de produção e desenvolvimento nessas plataformas.

Ainda preciso usar o Automation 360 Cloud, embora eu prefira usar o Automation Anywhere Enterprise Knowledge On-Premises? Ou, posso construir meu ambiente equivalente do Automation 360 Cloud nativo em um local totalmente fechado?

Não há implantação On-Premises do Automation 360 na nuvem com Kubernetes, Pod Services e serviços de API. O Enterprise Knowledge pode ser implantado ou On-Premises ou na nuvem como SaaS. O produto em si é o mesmo e pode ser usado em conjunto tanto com um ambiente do Automation 360 na nuvem quanto com um ambiente do Automation 360 On-Premises.

Quem implanta o ambiente On-Premises?

A instalação inicial é um esforço de colaboração entre os especialistas do Enterprise Knowledge e você. Você precisará fornecer SSH e acesso à rede para os computadores de implantação designados. Se o acesso direto não puder ser concedido, você precisará designar recursos técnicos que tenham o acesso necessário. Os especialistas do Enterprise Knowledge podem então orientar esses recursos remotamente por meio de compartilhamento de tela. Você é responsável por provisionar as máquinas necessárias. A instalação inicial e as atualizações subsequentes serão concluídas por meio de uma série de sessões que envolvem o download, a implementação e a configuração do software. O script de instalação incorporará conexões de CI/CD para recuperar ativos, realizar a instalação, configurar o sistema, implantar os componentes e habilitar futuras atualizações. É importante observar que a instalação e as atualizações não são algo que você gerenciará diretamente.

Você tem alguma estimativa de quanto tempo leva para implantar um sistema funcional?

A implantação pode variar de aproximadamente 4 horas a 2 semanas, dependendo de seu ambiente e requisitos específicos. Às vezes, nos deparamos com obstáculos, como certificados SSL ou alguém que não tem acesso total à rede para fazer alterações, e assim por diante. No entanto, em um cenário ideal, cerca de 4 horas para finalizar e testar.

Qual nó aceita os certificados SSL para conexões de entrada?

A maioria das implantações exigirá SSL, mas é possível que ele não seja implementado durante a implantação inicial. O servidor pode ser implantado sem SSL e configurado posteriormente. As portas de implantação específicas descritas no diagrama de arquitetura indicam onde os certificados SSL precisarão ser aplicados.

Os scripts são usados para a instalação?

Sim, os scripts do Terraform são utilizados atualmente para instalar todos os componentes. Esses scripts simplificam o processo de instalação e garantem resultados consistentes e repetíveis.

Há requisitos de armazenamento compartilhado?

Não, o armazenamento compartilhado de arquivos não é necessário. Os contêineres Docker e outros serviços usam o disco local scratch e o banco de dados PostgreSQL para todas as necessidades de armazenamento.

É necessário um disco SSD?

Sim, uma SSD (unidade de estado sólido) é um requisito. Os bancos de dados, especialmente os bancos de dados vetoriais, devido ao seu tamanho, são altamente sensíveis à latência do disco. Qualquer atraso no acesso ao disco afetará negativamente o desempenho.

O NAS é possível?
Não, o armazenamento conectado à rede (NAS) não é adequado. O NAS envolve disco compartilhado acessado por uma rede. Mesmo se for particionado e provisionado via iSCSI, a latência inerente da rede e a latência rotacional dos discos rígidos tradicionais (normalmente, o acesso é de 2,5 a 5 vezes mais lento do que a SSD) o tornam inadequado para os requisitos de desempenho.
Há alguma limitação nos recursos para On-Premises?
Não há limitações de recursos inerentes na implantação On-Premises. Recursos como rastreamento e Single Sign-On (SSO) são totalmente compatíveis. O acesso a recursos internos pode exigir a criação de listas de permissões de endereços IP ou domínios específicos em sua rede. A ativação do editor de documentos e do registro de suporte são configurações opcionais. A funcionalidade "Ações" pode também ser ativada ou desativada seletivamente. Vale a pena observar que os ambientes altamente restritos e sem acesso à Internet podem apresentar limitações de utilidade além das funcionalidades da rede local.
Há vários itens opcionais. O fato de não usá-los reduz as máquinas necessárias?
Não, a inclusão ou exclusão de recursos opcionais não afeta o número necessário de máquinas.
A máquina de sinalização sentinela está marcada como opcional, o que ela faz?
A máquina de sinalização sentinela, se ativada, oferece informações detalhadas de depuração por meio de registro, o que é útil para fins de suporte. Quando usada, geralmente é colocada em conjunto com outros componentes.
O editor de documentos é opcional? O que ele faz? Ele está instalado?
Sim, o editor de documentos é um recurso opcional e é uma função integrada ao console. Ele oferece funcionalidade de soquete da Web para edição de documentos em tempo real. O servidor de soquete da Web oferece suporte a esse recurso e pode ser utilizado para futuras ações baseadas em soquete da Web. Embora o editor possa não ser usado com frequência, ele permite que um usuário com direitos digite e edite diretamente documentos no sistema como uma atividade a ser adicionada à Base de Conhecimento (KB). Se a principal fonte de conhecimento for dados carregados ou rastreados, o editor de documentos será desnecessário. O contêiner Docker que hospeda o editor pode ser colocado em conjunto com outros componentes. No entanto, uma prática recomendada para adicionar conhecimento envolve a publicação do arquivo do documento em um local de conteúdo compartilhado padrão e, em seguida, o upload para a KB a partir desse ponto conhecido, seja por meio de rastreamento na Web ou de um processo automatizado.
Os LLMs são fornecidos?
Não, os grandes modelos de linguagem (LLMs) não são fornecidos diretamente com a implantação On-Premises. No entanto, as conexões integradas estão incluídas, permitindo o uso de créditos (semelhante à oferta de nuvem). Na maioria das implantações On-Premises, espera-se que você use conexões LLM personalizadas, utilizando seus próprios arranjos Bring Your Own Key (BYOK).
Como a implantação On-Premises afeta o uso de crédito ou o consumo de IA generativa BYOK?
Você tem a opção de usar créditos integrados para acessar os LLMs. No entanto, para um uso econômico e dimensionável dos LLMs e para aproveitar seus relacionamentos existentes com hiperescaladores ou outros fornecedores de LLMs de IA generativa, a maioria provavelmente empregará um modelo Bring Your Own Key (BYOK) para hospedar LLMs. Nesses casos, será necessário criar uma lista de permissões de conexões de saída para os respectivos provedores de serviços de LLM em sua rede.
Como o dimensionamento é tratado além da grande implantação totalmente distribuída?
Implantações totalmente distribuídas e dimensionadas atualmente se aplicam apenas à oferta em nuvem, e não a On-Premises. Embora uma implantação em nuvem maior envolva a expansão de servidores de pod e a iteração de contêineres Docker, as seguintes considerações se aplicam a On-Premises:
  • Na maioria dos casos, uma implantação On-Premises para você é uma única máquina.
  • Os componentes arquitetônicos detalhados servem principalmente para entender a estrutura geral, e a maioria não interage diretamente com eles após a implantação inicial.
  • A expansão além do nível totalmente distribuído grande não é atualmente compatível com implantações On-Premises.
  • Alta disponibilidade (HA) e recuperação de desastres (DR) não são compatíveis nativamente com On-Premises.

Arquitetura

Qual é a arquitetura para On-Premises?
A arquitetura On-Premises é baseada em Dockers e um banco de dados. Ela não usa imagens estáticas pré-criadas do Docker, mas emprega o Docker e o docker-compose para orquestração.
Qual banco de dados é usado?

O banco de dados usado é o PostgreSQL, que foi modificado para funcionar como um armazenamento de índice vetorial, conhecido como Supabase. Esse banco de dados personalizado será criado de acordo com os requisitos especificados, usando o script de instalação fornecido.

O banco de dados é um servidor independente ou pode ser RDS, Azure ou provisionado de outra forma na nuvem?

O banco de dados deve ser um servidor independente e precisa ser iniciado como uma máquina virtual (VM). Ele não pode ser substituído por serviços gerenciados de banco de dados na nuvem, como o AWS RDS Aurora, o Banco de Dados do Azure para PostgreSQL ou ofertas semelhantes provisionadas na nuvem. O servidor de banco de dados é um componente central de toda a implantação e requer configuração prática para se tornar um nó do Supabase totalmente funcional.

Como podemos fazer com que o Postgres se torne um Supabase? Não ouvimos falar do Supabase

Sim, o banco de dados deve residir em seu próprio servidor dedicado dentro da arquitetura. O Supabase pode ser entendido como o PostgreSQL com recursos aprimorados. Portanto, não é possível converter diretamente uma instância gerenciada do PostgreSQL existente ou qualquer outro tipo de banco de dados para Supabase. No entanto, é possível migrar dados de um para o outro. A instância do Supabase requer gerenciamento prático completo.

Os bancos de dados PostgreSQL provisionados por hiperescaladores são um bom ponto de partida?

Não. O banco de dados requer modificações específicas que exigem acesso e controle diretos. Os serviços gerenciados, como o AWS RDS, oferecem um uso mais abstrato e dividido da implementação do PostgreSQL e não proporcionam o nível de personalização necessário para transformá-lo em Supabase. O Supabase precisa ser implantado em uma VM, seja ela hospedada em uma plataforma de hiperescaladores ou em uma infraestrutura local.

Quais portas de acesso são usadas?

As seguintes portas precisam ser colocadas na lista de permissões para seus usuários e automações que acessam o servidor do Enterprise Knowledge: 80 (HTTP), 443 (HTTPS), 8000 (soquetes da Web HTTP/HTTPS), 8443 (soquetes da Web HTTP/HTTPS) e 1234 (soquetes da Web). É fundamental garantir que nenhum firewall de nível de aplicativo (camada 7) esteja bloqueando o acesso de usuários ou bots na sua rede. Observe que, em implantações de máquina única, a VM do Supabase e os contêineres Docker devem ser capazes de se comunicar totalmente. Da mesma forma, em implantações maiores e distribuídas, todas as máquinas precisam ter comunicação interna irrestrita.

Há suporte para SSL?

Sim, há suporte para SSL (Secure Sockets Layer). Isso requer um certificado SSL associado ao nome do host ou do domínio. Aqui estão as etapas gerais para a configuração do SSL em seu ambiente:

  • Adicione um registro no seu DNS que resolva o nome de host do nome de domínio totalmente qualificado (FQDN) para o endereço IP designado.
  • Você pode gerar um certificado SSL temporário e autoassinado usando ferramentas como o certbot para testes iniciais. No entanto, para ambientes de produção, é altamente recomendável apresentar um certificado SSL válido e uma chave privada para o nome de host FQDN.
  • Coloque o certificado SSL e os arquivos de chave nessa máquina dentro da pasta /nginx-proxy/ssl/.
  • Quando essas etapas forem concluídas, notifique a equipe de especialistas do Enterprise Knowledge para que eles possam finalizar as configurações necessárias no proxy Nginx para apontar para os arquivos SSL corretos.
  • Se o contêiner Docker do front-end for implantado separadamente da VM do Supabase, um conjunto separado de arquivos de certificado e chave deverá ser criado para os arquivos front-end.
Quais portas são usadas nos componentes da solução?
Tabela 1.
Finalidade Caminho Parâmetro Interno* Externo HTTP HTTPS WSS/WS
Front-end /app FRONTEND_SUFFIX 3000 X X
Nginx 80, 443 X X
Back-end /api BACKEND_SUFFIX 8001 X x
Automatizador /automator AUTOMATOR_SUFFIX 8002 x X
Redis 6379 x X
RabbitMQ 5672, 15672 x x
Editor de documentos /ws WEBSOCKET_SUFFIX 1234 1234 x x x
Gateway de API do Supabase Kong /supabase SUPABASE_SUFFIX 8000, 8443 8000**, 8443** x x
Supabase Postgres 6543 x x
PostgreSQL (automatizador) 5433 x x
Redis (automator) 6380 x x
Ollama 11434 x x ****

* Todas as máquinas internas devem ser capazes de se comunicar livremente umas com as outras

** apenas administrador

*** Recomendamos o uso de conexões SSL (https), mas podemos oferecer suporte a conexões http para PoCs

**** Aplica-se somente se estiver implantando o Ollama localmente

Quais portas os clientes (humanos, bots, API) usam?

Os clientes usam apenas 80/443. Outras portas são para comunicação interna, administração e implantação. O Nginx faz proxy de todos os acessos e saídas.

Quais métodos permitidos precisam ser ativados em minha rede?
Algumas redes ativam a filtragem de aplicativos com a camada 7 de aplicativos por meio de firewalls, aceleradores de aplicativos e alguns switches. É importante permitir os seguintes métodos para a solução em sua rede:
  • GET
  • PUBLICAR
  • COLOCAR
  • EXCLUIR
  • OPÇÕES
Se o sistema usa SSO, automatizador ou rastreamento, de qual nó a chamada é iniciada?
O SSO, assim como o acesso do cliente, é um serviço de front-end. Com o SSO, esse processo continua com o serviço de autenticação e, se a solicitação de autenticação for bem-sucedida, ele se conectará via webhook, concluindo a autenticação e gerando um token para uso posterior.
O rastreamento é um serviço de back-end, e todo o tráfego de entrada/saída é tratado pelo servidor final de back-end.
O automatizador é um serviço de back-end, e todo o tráfego de entrada/saída é tratado pelo servidor de front-end.
O Enterprise Knowledge pode usar proxies de encaminhamento?

Sim. O Nginx faz proxy de todo o tráfego de entrada e saída. A rede é sua, portanto, configure-a para permitir e autorizar o tráfego de ponta a ponta para que isso funcione.

E quanto ao gerenciamento de SSH?
O acesso SSH à caixa de implantação (máquina principal do banco de dados) será necessário para que nossos recursos técnicos realizem a instalação, as atualizações e qualquer solução de problemas necessária.
Para facilitar esse acesso:
  • Você precisa configurar as chaves SSH necessárias e o acesso à rede para nossos recursos específicos nas máquinas base.
  • Se a sua equipe não puder fornecer acesso direto, solicitaremos recursos técnicos designados da sua equipe. Esses recursos devem ter o acesso necessário. Eles devem estar disponíveis quando necessário para instalação, atualizações e solução de problemas.
  • Nossos recursos especialistas do Enterprise Knowledge e os seus próprios recursos técnicos terão uma colaboração estreita. Eles coordenarão as etapas necessárias. Você pode conseguir essa coordenação por meio do acesso compartilhado de TI, como uma reunião com tela compartilhada.
  • As sessões técnicas coordenadas podem levar tempo. O download e a execução de scripts de implantação mais longos levam tempo. O suporte de nossos especialistas do Enterprise Knowledge provavelmente envolverá várias sessões. Portanto, os recursos designados devem estar preparados para iniciar, pausar, continuar e parar conforme necessário.
Os dados são criptografados em repouso e em trânsito?
Sim, SSL e TLS 1.2 são usados para dados em trânsito.
Sim, AES 256 é usado para dados em repouso. Além disso, é possível gerar e definir uma chave de criptografia para instalações OnPrem como parte do script de configuração inicial.
Como o SSO pode ser aplicado?
O SSO é compatível com protocolos como Okta, Azure AD e SAML 2.0.
O que proporciona alta disponibilidade (HA)?
Uma consideração importante para as implantações OnPrem é que a sua equipe de TI é responsável por gerenciar as interrupções de rede e garantir a alta disponibilidade (HA). A instalação do Enterprise Knowledge, especialmente para configurações que excedam um único servidor, não inclui tolerância a falhas incorporada. Portanto, um exercício de dimensionamento é essencial para projetar uma arquitetura adequada que seja dimensionada e atenda aos seus requisitos de HA.
O que precisa ser armazenado em backup?
Tudo (a configuração e os parâmetros) é armazenado no banco de dados. Um backup agendado do banco de dados tratará das operações de backup e restauração.
As imagens do Docker estão sendo usadas atualmente?
No momento, as imagens do Docker não são usadas diretamente. No entanto, as imagens do Docker podem ser montadas quando os arquivos docker-compose estiverem disponíveis.
O que permite o dimensionamento automático do Docker?
Os contêineres do Docker são usados para implantações, exigindo o Docker v27.1.1 ou superior. O exercício de dimensionamento com a equipe de especialistas determinará se a solução requer dimensionamento com escala automática para a API e os funcionários, bem como qualquer distribuição de servidores para uma implantação totalmente distribuída.
Os clientes precisam de um registro do Docker?
Nº