Preguntas frecuentes sobre Automation Anywhere Enterprise Knowledge de On-Premises

Consulte esta sección de preguntas frecuentes para ver preguntas comunes y respuestas detalladas sobre la implementación On-Premises de la plataforma Automation Anywhere Enterprise Knowledge, que abarca desde la definición y arquitectura On-Premises hasta los requisitos de infraestructura, los procesos de implementación, las consideraciones de seguridad y más.

Implementación

¿La instalación de Enterprise Knowledge On-Premises será compatible con la instalación en AWS, GCP, Azure o máquinas físicas y virtuales como VMWare?

Sí, tenemos las especificaciones necesarias para ambos entornos de Producción y Desarrollo en estas plataformas.

¿Todavía necesito usar Automation 360 Cloud aunque prefiero usar Automation Anywhere Enterprise Knowledge On-Premises? O, ¿puedo construir mi entorno equivalente nativo de Automation 360 Cloud en un entorno completamente cerrado?

No hay una implementación On-Premises de la nube Automation 360 con Kubernetes, módulos de servicios y servicios de API. Enterprise Knowledge se puede implementar On-Premises o en la nube como SaaS. El producto en sí es el mismo y se puede usar junto con Automation 360 en entorno de nube y con Automation 360 On-Premises.

¿Quién implementa el entorno On-Premises?

La instalación inicial es un esfuerzo colaborativo entre los expertos en conocimiento empresarial y usted. Deberá facilitar acceso SSH y de red a las máquinas de implementación designadas. Si no se puede otorgar acceso directo, necesitará asignar recursos técnicos que posean el acceso requerido. Los expertos en conocimiento de Enterprise Knowledge pueden guiar estos recursos de forma remota mediante el uso compartido de pantalla. Usted es responsable de aprovisionar las máquinas necesarias. La instalación inicial y las actualizaciones posteriores se completarán a través de una serie de sesiones que involucran la descarga, implementación y configuración del software. La secuencia de comandos de instalación incorporará conexiones CI/CD para recuperar activos, realizar la instalación, configurar el sistema, implementar los componentes y habilitar futuras actualizaciones. Es importante tener en cuenta que la instalación y las actualizaciones no son algo que gestionará directamente.

¿Tienen alguna estimación de cuánto tiempo lleva implementar un sistema funcional?

La implementación puede variar desde aproximadamente 4 horas hasta 2 semanas, dependiendo de su entorno y de los requisitos específicos. A veces, nos encontramos con obstáculos, como certificados SSL o alguien que no tiene acceso completo a la red para hacer cambios, y así sucesivamente. Pero, en un escenario ideal, lleva alrededor de 4 horas finalizar y probar la implementación.

¿Qué nodo acepta los certificados SSL para conexiones entrantes?

La mayoría de las implementaciones requerirán SSL, pero podría no implementarse durante la implementación inicial. El servidor se puede implementar sin SSL y configurarse más tarde. Los puertos de implementación específicos descritos en el diagrama de arquitectura indican dónde se deberán aplicar los certificados SSL.

¿Se utilizan secuencias de comando para instalar?

Sí, las secuencias de comando de Terraform se utilizan actualmente para instalar todos los componentes. Estas secuencias de comando simplifican el proceso de instalación y garantizan resultados consistentes y repetibles.

¿Existen requisitos de almacenamiento compartido?

No, no es necesario el almacenamiento de archivos compartidos. Los contenedores de Docker y otros servicios utilizan el disco local borrador y la base de datos PostgreSQL para todas las necesidades de almacenamiento.

¿Se requiere un disco SSD?

Sí, una unidad de estado sólido (SSD) es un requisito. Las bases de datos, particularmente las bases de datos vectoriales debido a su tamaño, son muy sensibles a la latencia del disco. Todos los retrasos en el acceso al disco impactarán negativamente el rendimiento.

¿Es posible utilizar un NAS?
No, el almacenamiento conectado a la red (NAS) no es adecuado. El NAS implica un disco compartido al que se accede a través de una red. Incluso si se particiona y aprovisiona a través de la interfaz de sistemas de pequeños ordenadores de Internet (iSCSI), la latencia de red inherente y la latencia de rotación de los discos duros tradicionales (normalmente de 2,5 a 5 veces más lentos de acceso que las SSD) los hacen inadecuados para los requisitos de rendimiento.
¿Existe alguna limitación en las funciones para las implementaciones On-Premises?
No existen limitaciones inherentes de funciones en la implementación On-Premises. Las capacidades como el rastreo y el inicio de sesión único (SSO) son totalmente compatibles. El acceso a recursos internos puede requerir la inclusión en la lista blanca de direcciones IP o dominios específicos dentro de su red. Habilitar el editor de documentos y el registro de soporte son configuraciones opcionales. La funcionalidad de "Acciones" también se puede habilitar o deshabilitar selectivamente. Hay que tener en cuenta que los entornos muy restringidos sin acceso a Internet pueden experimentar limitaciones en su utilidad más allá de las funcionalidades de la red local.
Hay varios elementos opcionales. ¿No utilizarlas reduce las máquinas necesarias?
No, la inclusión o exclusión de funciones opcionales no afecta al número de máquinas necesario.
La máquina de señalización de centinela está marcada como opcional, ¿qué hace?
La máquina de señalización de centinela, si está habilitada, facilita información detallada de depuración a través de registros, lo cual es valioso para propósitos de soporte. Cuando se usa, se suele colocar junto con otros componentes.
El editor de documentos es opcional, ¿qué hace y está ubicado?
Sí, el editor de documentos es una función opcional y es una función integrada dentro de la consola. Brinda funcionalidad de web socket para la edición de documentos en tiempo real. El servidor de web socket admite esta función y se puede utilizar para futuras acciones basadas en web socket. Aunque es posible que el editor no se utilice con frecuencia, le permite a un usuario con derechos escribir y editar directamente documentos dentro del sistema como actividad para añadirlos a la Base de conocimientos (KB). Si la principal fuente de conocimiento son los datos cargados o rastreados, el editor de documentos es prácticamente innecesario. El contenedor Docker que aloja el editor puede ubicarse junto con otros componentes. Sin embargo, una de las mejores prácticas para añadir conocimiento consiste en publicar el archivo del documento en una ubicación estándar de contenido compartido y luego subirlo a la KB desde ese punto conocido, ya sea mediante rastreo web o un proceso automatizado.
¿Se proporcionan modelos de lenguaje extenso (LLM)?
No, los modelos de lenguaje extenso (LLM) no se proporcionan directamente con la implementación On-Premises. Sin embargo, se incluyen conexiones integradas, lo que permite el uso de créditos (similar a la oferta en la nube). En la mayoría de las implementaciones On-Premises, se anticipa que utilizará conexiones LLM personalizadas, utilizando sus propios acuerdos de "traiga su propia clave" (BYOK).
¿Cómo afecta la implementación On-Premises el uso de crédito o el consumo de IA generativa con BYOK?
Tiene la opción de usar créditos integrados para acceder a los LLM. Sin embargo, para el uso rentable y escalable de LLM, y para aprovechar sus relaciones existentes con hiperescaladores u otros proveedores de IA generativa de LLM, la mayoría probablemente empleará un modelo de "traiga su propia clave" (BYOK) para alojar LLM. En estos casos, será necesario incluir en la lista blanca las conexiones salientes a los respectivos proveedores de servicios LLM dentro de su red.
¿Cómo se gestiona la ampliación a partir de una gran implementación totalmente distribuida?
Las implementaciones totalmente distribuidas y ampliadas actualmente solo se aplican a la oferta en la nube, no On-Premises. Mientras que una implementación en la nube más grande implicaría escalar servidores de módulos e iterar contenedores de Docker, se aplican las siguientes consideraciones a On-Premises:
  • En la mayoría de los casos, una implementación On-Premises para usted es una sola máquina.
  • Los componentes arquitectónicos detallados son principalmente para comprender la estructura general, y directamente no se interactúa con la mayoría con ellos después de la implementación inicial.
  • Actualmente no se admite la ampliación por encima del nivel de distribución completa para las implementaciones On-Premises.
  • La alta disponibilidad (HA) y la recuperación ante desastres (DR) no son compatibles de forma predeterminada en implementaciones On-Premises.

Arquitectura

¿Cuál es la arquitectura para implementaciones On-Premises?
La arquitectura para implementaciones On-Premises se basa en Dockers y en una base de datos. No utiliza imágenes Docker estáticas preconstruidas, sino que emplea Docker y Docker-Compose para la orquestación.
¿Qué base de datos se utiliza?

La base de datos que se utiliza es PostgreSQL, que se ha modificado para que funcione como un almacén de índices vectoriales, conocido como Supabase. Esta base de datos personalizada se construirá de acuerdo con los requisitos especificados utilizando la secuencia de comandos de instalación proporcionada.

¿La base de datos es un servidor independiente, o puede ser RDS, Azure o estar en la nube?

La base de datos debe ser un servidor independiente y debe iniciarse como una máquina virtual (MV). No se puede sustituir por servicios gestionados de bases de datos en la nube como AWS RDS Aurora, Azure Database para PostgreSQL u ofertas similares proporcionadas en la nube. El servidor de base de datos es un componente central de la implementación completa y requiere una configuración práctica para convertirse en un nodo Supabase totalmente funcional.

¿Cómo conseguir que Postgres se convierta en Supabase? No hemos oído hablar de Supabase.

Sí, la base de datos debe residir en su propio servidor dedicado dentro de la arquitectura. Supabase puede entenderse como PostgreSQL con capacidades mejoradas. Por lo tanto, no puede convertir directamente una instancia PostgreSQL administrada existente o cualquier otro tipo de base de datos en Supabase. Sin embargo, migrar datos de uno a otro es posible. La instancia de Supabase requiere una gestión completa y práctica.

¿Son las bases de datos PostgreSQL aprovisionadas por hiperescaladores un buen punto de partida?

No. La base de datos requiere modificaciones específicas que necesitan acceso y control directos. Los servicios administrados, como AWS RDS, ofrecen un uso más abstracto y segmentado de la implementación de PostgreSQL y no proporcionan el nivel de personalización necesario para transformarlo en Supabase. Es preciso desplegar Supabase en una MV, ya sea que esté alojada en una plataforma hiperescaladora o en una infraestructura local.

¿Qué puertos de acceso se utilizan?

Los siguientes puertos deben estar en la lista blanca para que sus usuarios y automatizaciones accedan al servidor de Enterprise Knowledge: 80 (HTTP), 443 (HTTPS), 8000 (web sockets HTTP/HTTPS), 8443 (web sockets HTTP/HTTPS) y 1234 (web sockets). Es crucial asegurarse de que ningún firewall a nivel de aplicación (nivel 7) esté bloqueando el acceso para usuarios o bots dentro de su red. Tenga en cuenta que en las implementaciones de una sola máquina, la MV Supabase y los contenedores Docker deben poder comunicarse completamente. De manera similar, en implementaciones más grandes y distribuidas, todas las máquinas necesitan tener comunicación interna sin restricciones.

¿Se admite SSL?

Sí, se admite la capa de sockets seguros (SSL). Esto requiere un certificado de SSL asociado con el nombre de host o dominio. Estos son los pasos generales para la configuración de SSL en su entorno:

  • Agregue un registro en su sistema de nombres del dominio (DNS) que resuelva el nombre de host del dominio completo (FQDN) en la dirección IP designada.
  • Puede generar un certificado SSL temporal y autofirmado usando herramientas como certbot para pruebas iniciales. Sin embargo, para entornos de producción, recomendamos encarecidamente proporcionar un certificado SSL válido y una clave privada para el nombre de host FQDN.
  • Coloque los archivos de certificado SSL y clave en esa máquina dentro de la carpeta /nginx-proxy/ssl/.
  • Una vez que estos pasos se completen, notifique al equipo de Enterprise Knowledge SME para que puedan finalizar las configuraciones necesarias en el proxy Nginx para apuntar a los archivos SSL correctos.
  • Si el contenedor de Docker de frontend se despliega por separado de la MV de Supabase, se debe crear un conjunto separado de archivos de certificado y clave para el frontend.
¿Qué puertos se utilizan dentro de los componentes de la solución?
Tabla 1.
Objetivo Ruta Parámetro Interno* Externo HTTP HTTPS WSS/WS
Frontend /app FRONTEND_SUFFIX 3000 X X
Nginx 80, 443 X X
Backend /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
Puerta de enlace Supabase Kong API /supabase SUPABASE_SUFFIX 8000, 8443 8000**, 8443** x x
Supabase Postgres 6543 x x
PostgreSQL (automatizador) 5433 x x
Redis (automatizador) 6380 x x
Ollama 11434 x x ****

* Todas las máquinas internas deben poder comunicarse libremente entre sí.

** solo administrador.

*** Recomendamos usar conexiones SSL (https), pero las conexiones http para PoC son compatibles.

**** Solo aplica si se implementa Ollama de manera local.

¿Qué puertos utilizan los clientes (humanos, bots, API)?

Los clientes solo usan 80/443. Otros puertos son para comunicación interna y administración e implementación. Nginx controla todos los accesos y salidas.

¿Qué métodos permitidos se deben habilitar en mi red?
Algunas redes activan el filtrado de aplicaciones con el nivel 7 a través de firewalls, aceleradores de aplicaciones y algunos conmutadores. Es importante que permita los siguientes métodos para la solución dentro de su red:
  • OBTENER
  • PUBLICAR
  • PONER
  • ELIMINAR
  • OPCIONES
Si el sistema utiliza SSO, automatizador o rastreo, ¿desde qué nodo se inicia la llamada?
SSO, como el acceso de cliente, es un servicio de frontend. Con SSO, este proceso continúa con el servicio de autenticación, y si la solicitud de autenticación se realiza correctamente, se conecta a través de webhook, completa la autenticación y genera un token para su uso posterior.
El rastreo es un servicio backend, y el servidor final gestiona todo el tráfico de entrada y salida.
El automatizador es un servicio backend, y todo el tráfico de entrada/salida se gestiona en el servidor frontend.
¿Puede Enterprise Knowledge usar proxies directos?

Sí. Nginx procesa todo el tráfico de entrada y salida. Es su red, por lo que configúrela para permitir y autorizar el tráfico de principio a fin para que esto funcione.

¿Qué ocurre con la gestión SSH?
El acceso SSH a la caja de implementación (máquina de base de datos principal) será necesario para que nuestros recursos técnicos realicen la instalación, las actualizaciones y solucionen cualquier problema que se requiera.
Para facilitar este acceso debe hacer lo siguiente:
  • Es necesario configurar las claves SSH necesarias y el acceso a la red para nuestros recursos específicos en las máquinas base.
  • Si su equipo no puede facilitar el acceso directo, necesitamos recursos técnicos designados de su equipo. Estos recursos deben tener el acceso necesario. Deben estar disponibles cuando se necesiten para la instalación, las actualizaciones y la resolución de problemas.
  • Nuestros recursos SME de Enterprise Knowledge y sus recursos técnicos colaborarán estrechamente. Ellos coordinarán los pasos requeridos. Puede conseguir esta coordinación a través de un acceso compartido de TI, como una reunión con pantalla compartida.
  • Las sesiones técnicas coordinadas pueden requerir tiempo. Descargar y ejecutar secuencias de comandos de implementación más largas lleva tiempo. Es probable que el apoyo de nuestros SME de Enterprise Knowledge implique varias sesiones. Por lo tanto, los recursos designados deben estar preparados para arrancar, pausar, continuar y parar según sea necesario.
¿Los datos están cifrados en reposo y en curso?
Sí, SSL y seguridad de capa de transporte (TLS) 1.2 se utilizan para los datos en tránsito.
Sí, se utiliza AES 256 para los datos en reposo. Además, es posible generar y establecer una clave de cifrado para las instalaciones OnPrem como parte de la secuencia de comandos de configuración inicial.
¿Cómo se puede aplicar el inicio de sesión único (SSO)?
El SSO es compatible a través de protocolos como Okta, Azure AD y SAML 2.0.
¿Qué proporciona la alta disponibilidad (HA)?
Una consideración clave para las implementaciones OnPrem es que su equipo de TI es responsable de gestionar las interrupciones de la red y garantizar la alta disponibilidad (HA). La instalación de Enterprise Knowledge, en particular para las configuraciones de más de un único servidor, no incluye tolerancia a fallos integrada. Por lo tanto, es esencial realizar un ejercicio de calibración para diseñar una arquitectura adecuada que se adapte y cumpla sus requisitos de HA.
¿De qué hay que hacer copias de seguridad?
Todo, la configuración y los parámetros, se almacena en la base de datos. Una copia de seguridad programada de la base de datos se encargará tanto de las operaciones de copia de seguridad como de las de restauración.
¿Se utilizan actualmente imágenes de Docker?
Las imágenes de Docker no se utilizan directamente en este momento. Sin embargo, las imágenes de Docker se pueden ensamblar a medida que los archivos Docker-Compose están disponibles.
¿Qué habilita el autoescalado de Docker?
Los contenedores Docker se utilizan para las implementaciones y requieren Docker v27.1.1 o superior. El ejercicio de calibración con el equipo de SME determinará si la solución requiere un calibrado con autoescalado para la API y los trabajadores, así como cualquier distribución de servidores hacia una implementación totalmente distribuida.
¿Los clientes necesitan un registro de Docker?
No.