Introducción
La información aquí presentada indica los aspectos técnicos más críticos que debe considerar en su infraestructura corporativa con el objetivo de establecer un sistema de arquitectura Bizagi que se ejecute bajo condiciones óptimas y de acuerdo a las recomendaciones oficiales hechas por Bizagi Ltd.
Antes de comenzar
La información que se dará a continuación es complementaria al análisis de tamaño, la cual se deberá llevar a cabo para su proyecto específico (tamaño del hardware). Encontrará documentación detallada acerca de los requerimientos específicos del sistema (soportado en configuración de software y versiones).
Para obtener mayor información acerca de los requerimientos del sistema, refiérase al siguiente elnace:
•Alta disponibilidad .NET- requerimientos del sistema
Ésta información no le proporcionará una guía para instalar o configurar Automation Server ni ninguno de sus componentes requeridos.
Conceptos
Las mejores prácticas y requerimientos presentados en ésta sesión consideran un sistema de arquitectura corporativo en Bizagi con los siguientes conceptos.
Alta disponibilidad
Una arquitectura de alta disponibilidad está diseñada para soportar los sistemas con mayor exactitud (mejorando el tiempo de servicio), mientras implica el uso redundante de los activos de TI que evitan puntos de falla (por ejemplo, la misión crítica de los procesos de negocio).
Por lo tanto, las recomendaciones comunes tales como utilizar una fuente de alimentación redundante para sus servidores o el mantenimiento en la configuración de servidores idénticos a través de clústeres, son válidos para el sistema de arquitectura de Bizagi (junto a otras medidas similares).
Bizagi soporta alta disponibilidad soportando la configuración de los clústeres a través de sus diferentes niveles, mientras permite la futura escalación como solución en cualquier momento.
Arquitectura de producto de Bizagi
Bizagi es una aplicación de acceso a datos que se ejecuta de forma ligera en un servidor dado y no genera un código de intermediación.
Por lo tanto y siendo guiadas por un modelo, es importante que asegure la infraestructura subyacente para Bizagi cuando esté accediendo a datos, proporcionando de esta manera una ejecución óptima (evitando los cuellos de botella en el acceso a los datos).
En relación a este diseño de arquitectura, es importante que sus ejecuciones DBA realicen un monitoreo continuamente ajustando tareas, tales como: Certificar la integridad de la base de datos, actualizar las estadísticas de las bases de datos, re organizar y mantener índices, ejecutar reducciones adecuadas u observar el comportamiento del crecimiento de la base de datos (por ejemplo, grupos de archivos, espacios de tablas).
Las recomendaciones más comunes en relación al mantenimiento y el ajuste, emitidas por el proveedor de la base de datos Engine, se aplican a la base de datos de Bizagi.
Referencia del sistema de arquitectura
Los siguientes diagramas ilustran una arquitectura general del sistema de Bizagi para una configuración corporativa.
Las sub-secciones que se describen a continuación elaborarán las mejores prácticas y requerimientos para considerar los diferentes activos en cada nivel.
Nivel de Base de Datos (Database tier)
El nivel de la base de datos (capa de acceso a los datos) es donde el motor de la base de datos es instalado (por ejemplo, SQL Server, Oracle).
Para obtener alta disponibilidad, use 2 o más nodos en la configuración del clúster en la base de datos (principalmente para las capacidades o para usar una distribución activo-activo cuando esté utilizando Oracle RAC).
Los siguientes diagramas señalan la configuración del nivel de base de datos, y los aspectos críticos que permiten un mejor rendimiento con Bizagi:
Como se ha puntualizado en la imagen, debe considerar:
1. SERVIDOR DB
•Es altamente recomendado para usar un servidor de base de datos dedicado para alojar exclusivamente una base de datos Bizagi.
Esto se hace con el objetivo de evitar tomar los recursos de alojamiento de otras bases de datos y terminar afectando Bizagi (o viceversa).
•Asignar lo más posible de RAM a los servidores de bases de datos, y de acuerdo al tamaño estimado de su proyecto, teniendo en cuenta que podrá escalar el servidor de la base de datos en términos de asignación RAM.
2. RED QUE INVOLUCRA NODOS Y ALMACENAMIENTO
•Asegure una configuración de la red óptima para la configuración del clúster.
Las características óptimas de una red deben considerar un nivel de latencia bajo (por ejemplo, por lo general logra hacer que los nodos de una base de datos en un cluster en un mismo segmento de red o se conectan directamente).
•Apóyese en el motor de la base de datos y las recomendaciones oficiales al configurar un clúster.
Las recomendaciones comunes se aplicarán, tales como el uso de tarjetas de red redundantes para la sincronización de clusteres.
3. DESEMPEÑO DEL REPOSITORIO FÍSICO DE LOS DATOS
•Un desempeño óptimo del repositorio físico de los datos incluye las siguientes mejores prácticas cuando se esté configurando un SAN, de igual manera, se provee una baja latencia entre los nodos de las bases de datos y el almacenamiento compartido, mientras asegura una alta velocidad para los discos del almacenamiento subyacente (por ejemplo, uso de unidades de estado sólido) de manera que los procesos de input/output no se conviertan en cuellos de botella.
•En relación a los archivos de las bases de datos, es muy importante que un software de antivirus no escanee o interfiera con ellos.
4. BIZAGI ODS.
•El uso de los ODS de Bizagi le permite usar las funcionalidades BI sin afectar los recursos asignados para las operaciones transaccionales.
A través de esta opción, las funcionalidades BI (que no son utilizadas como parte crítica del trabajo diario, tales como procesos analíticos o reportes) se ejecutan en bases de datos separadas que se configuran replicando las tecnologías de la bases de datos por segundos.
De esta manera, la ejecución de las consultas que involucran volúmenes altos de información no impactan las operaciones de sus procesos especialmente si su sistema es altamente concurrente.
Red entre la base de datos y Bizagi
La red entre la base de datos y Bizagi tiene un importante papel en el sistema de arquitectura de Bizagi.
El siguiente diagrama señala la parte y el aspecto que son críticos para generar un mejor rendimiento con Bizagi:
Tal como se mencionó anteriormente debe considerar:
1. SERVIDORES BIZAGI A BASES DE DATOS
•Las características óptimas de la red entre la base de datos y Bizagi debe considerar una baja latencia (por ejemplo, usualmente consume teniendo estos servidores en un mismo segmento de red, usualmente con un switch entre ellos).
•Es importante que el promedio de la latencia sea 0,15 ms
Se sugiere un ancho de banda que considere al menos 10,000 kb in 64ms.
Niveles de los procesos digitales
Los niveles de los procesos digitales son donde Automation Server ejecuta.
Para alta disponibilidad, use 2 o más nodos en Bizagi para la configuración de los clústeres mediante la carga de las habilidades de balance.
El siguiente diagrama señala la configuración de los niveles, y qué aspectos son críticos para mejorar el rendimiento con Bizagi:
Como se señaló anteriormente, considere:
1. BALANCEADOR DE CARGA
•Use un balanceador de carga (basado en hardware) como por ejemplo f5.
Los dispositivos de hardware que proporcionan capacidades de balanceo de carga son conocidos para soportar la alta concurrencia y en general, mejorar el desempeño de los equilibra dores de carga basados en software.
•Mientras esté utilizando un balanceador de carga, asegúrese de usar una configuración de sesiones por afinidad sin importar el algoritmo utilizado (ejemplo, en un entorno .NET, este concepto es conocido como sticky sessions).
2. CONFIGURACIÓN DEL CLÚSTER
•Siguiendo las mejores prácticas de la configuración de un clúster las cuales son emitidas por el fabricante de su motor en su base de datos.
Las recomendaciones comunes, como el uso de una configuración de servidores idénticos para todos los nodos en un clúster, o la deshabilitación de la operación de las actualizaciones automáticas del sistema que se aplicarán a los servidores de Bizagi.
•Mientras se mantiene una configuración idéntica del servidor para todos los nodos, asegúrese de usar la misma cuenta de servicios al motor de la base de datos, la misma cuenta de servicios para la iniciación de la aplicación ( y para futuros accesos a los documentos adjuntos del servidor) y la misma configuración para conectar al servicio SMTP.
Para una mayor seguridad en el análisis del tamaño del hardware y cargar algoritmos balanceados, use un servidor dedicado para almacenar Automation Server.
Red para usuarios finales
La red para los usuarios finales que tienen acceso a Bizagi no demanda términos de ancho de banda, aunque debería implementar medidas de seguridad significativas.
El siguiente diagrama señala esta parte y los aspectos críticos para acceder de manera segura a Bizagi:
Como se mencionó anteriormente, tenga en cuenta:
1. USUARIOS FINALES A BIZAGI
•El acceso seguro a Bizagi se promueve configurando un soporte HTTPS.
No existen consideraciones especiales que se requieren en términos de conectividad de red ofrecidas a los usuarios finales para acceder a Bizagi (Automation Server es optimizado y diseñado para soportar la conexión de los usuarios finales desde Internet o trabajando en una red general lenta).
La especificación del ancho de banda se une principalmente al tamaño del archivo de los documentos adjuntos de sus procesos de negocio.
•Apóyese en un dispositivo robusto de firewall, así como medidas de seguridad reforzada (por ejemplo, Barracuda)
Otros aspectos
En relación a la integración con sus sistemas corporativos, apóyese en su ESB cuando sea aplicable (para soportar la continuidad del negocio) mientras asegura de igual manera que la conectividad de la red al ESB o a otros sistemas es óptima.
Una conectividad de una red óptima tiene en cuenta una banda de ancho acorde al volumen esperado de la información que va a ser transmitida (por ejemplo, considere el tamaño de los documentos adjunto a los procesos cuando se envían a otro sistema, o el la cantidad total de información que se intercambia cuando se invocan servicios web externos o escenarios de integración B2B en general).