Las siguientes consideraciones se organizan en torno a los pilares de arquitectura del marco de trabajo bien arquitectado de ArcGIS. La aplicación apropiada de las prácticas recomendadas y los planteamientos arquitectónicos en cada una de estas áreas técnicas contribuye de forma significativa al diseño y la implementación correctos de sistemas bien diseñados.
La elección de diseñar para la separación de cargas de trabajo se hizo para ayudar a lograr una distribución óptima de los recursos de cálculo en todo el sistema. En el estudio de prueba, las solicitudes de edición tardaban generalmente más tiempo en procesarse que las solicitudes de mapas estándar, por lo que se optó por aislar las cargas de trabajo de edición con recursos de cálculo dedicados en forma de un sitio ArcGIS GIS Server separado. Además, aislar los propios componentes del sistema en otros equipos ayuda a garantizar que no compiten por los recursos del sistema y permite adaptar los tipos y tamaños de las máquinas a los requisitos del sistema de cada componente.
Seleccionar la GPU (unidad de procesamiento gráfico) adecuada es fundamental para garantizar el rendimiento de ArcGIS Pro en un entorno virtualizado. Las pruebas revelaron que agregar una GPU dedicada a los equipos virtuales de ArcGIS Pro mejoraba significativamente la productividad del usuario final y producía una reducción neta del coste si se tenían en cuenta los gastos operativos (costes de mano de obra). Más información sobre la selección de hardware de GPU y la virtualización de ArcGIS Pro en el Centro de arquitectura de ArcGIS.
Es importante conocer el ratio entre la CPU virtual (vCPU) y la CPU física a la hora de tomar decisiones de diseño para poder asignar los recursos apropiados a los componentes del sistema. Hay un ratio 2:1 de vCPU:CPU para todos los equipos del diagrama, pero algunas opciones de virtualización pueden tener otros ratios, como 1:1. Estas decisiones también pueden tener implicaciones para el licenciamiento de Esri. Algunos ejemplos de ratios de nube pública son AWS, Azure y GCP.
La configuración adecuada de los servicios SIG es fundamental para el rendimiento del sistema y la satisfacción de la experiencia del usuario, y la configuración incorrecta de las instancias de servicios SIG puede introducir problemas o retos de fiabilidad en un sistema. Por ejemplo, si el número de instancias para un servicio de mapas o de entidades es demasiado bajo, pueden producirse largos tiempos de espera de los clientes y errores de tiempo de espera.
Sin embargo, establecer un recuento de instancias demasiado alto puede consumir excesivos recursos del equipo, limitando el número de servicios que pueden implementarse en una configuración de hardware fija. Cuando el ajuste de instancia máxima es superior al mínimo, el sistema puede agregar automáticamente nuevas instancias en respuesta a la demanda, pero esto también puede ser problemático porque las solicitudes entrantes deben esperar a que se inicie la instancia. Para cualquier sistema, es importante comprender el uso del servicio para poder ajustar el número de instancias y los recursos del servidor con el fin de proporcionar un rendimiento óptimo.
En este estudio de prueba, el ratio entre instancias de servicio y núcleos físicos de CPU se fijó en 2:1 para cada servicio relevante, con los ajustes de instancias mínimas y máximas configurados en ese mismo valor. Se monitorizó el uso de instancias para determinar cuándo se sobrecargaba el sistema. Por ejemplo, con una carga de diseño de 8, las instancias de servicio para un servicio en el servidor de alojamiento se observaron activas durante el 99 % del periodo de prueba, lo que provocó tiempos de espera elevados para los servicios de solo lectura. Los servicios de esta prueba se configuraron para instancias dedicadas. Más información sobre cómo configurar los ajustes de instancia de servicio.
En este estudio de prueba, los servicios de red de servicios se configuraron de la siguiente manera:
El número total de instancias disponibles era de 16 porque había dos servidores SIG ArcGIS en el sitio. Los servidores de alojamiento se configuraron de la siguiente manera:
El número total de instancias disponibles era de 12 porque había dos servidores SIG ArcGIS en el sitio.
Los tiempos de espera de servicio especificados se configuraron de la siguiente manera:
Nuestra configuración de tiempo de espera se ajustó de forma iterativa para abordar los tiempos de espera encontrados durante el proceso de prueba. Dado que esta configuración puede variar según los requisitos específicos, se recomienda realizar sus propias pruebas para identificar la configuración más óptima.
Las copias de seguridad son fundamentales para los sistemas de administración de información de red. Consulte la arquitectura de referencia para obtener más información. Aunque el diseño probado no era un sistema de producción, se capturaron instantáneas de los equipos y copias de seguridad de las bases de datos para cada prueba y antes de realizar cualquier cambio en el sistema. Las instantáneas de las máquinas virtuales se tomaron antes y después de cualquier cambio en el entorno (como redimensionar un equipo, instalar un parche o actualizar Windows). A continuación, se catalogaron las instantáneas para habilitar:
La elección de diseñar este sistema con una configuración de alta disponibilidad de los componentes de ArcGIS Enterprise se hizo basándose en los requisitos empresariales y técnicos del sistema, junto con otros objetivos organizativos como lograr operaciones ininterrumpidas y reducir el tiempo de inactividad. Esta configuración se ilustra en el diseño con componentes de sistema redundantes y un almacén en la nube de alta disponibilidad para el almacenamiento de archivos. En este estudio de prueba no se configuró una base de datos de alta disponibilidad con fines de prueba, aunque los proveedores de bases de datos relacionales disponen de diversos métodos para plantear la alta disponibilidad, incluidos los servicios nativos en la nube.
Tenga en cuenta que las configuraciones de alta disponibilidad pueden aumentar significativamente los costes operativos y de infraestructura del sistema y que se requieren conocimientos especializados para tener éxito. Más información sobre las opciones de diseño y las consideraciones relativas a la alta disponibilidad para un sistema de administración de información de red.
Para realizar correctamente la validación del sistema y obtener resultados significativos, la monitorización del sistema y la captura de telemetría fueron orientaciones clave para el estudio de prueba.
Se utilizaron ArcGIS Monitor y herramientas empresariales de monitorización de TI como Windows Performance Monitor para supervisar el rendimiento del sistema y capturar telemetría sobre su comportamiento en determinadas condiciones. Se recopilaron registros de distintos componentes del sistema, entre ellos:
Se capturaron métricas a nivel de equipo como el uso de la CPU, el consumo de RAM, la actividad del disco y la actividad de la red en todos los equipos del entorno. Consulte los resultados de las pruebas para obtener más información.
Además, se capturaron grabaciones de pantalla de los flujos de trabajo realizados para observar y evaluar la experiencia y la productividad del usuario final.
Dado que el alcance del estudio de pruebas se centraba principalmente en las pruebas de carga, no se emplearon la mayoría de los tipos de automatización que se recomendarían para un sistema de producción (como la creación de scripts para tareas administrativas). Sin embargo, en su entorno, los scripts administrativos pueden tener un valor significativo para los flujos de trabajo y las operaciones. Cualquier script de automatización debe probarse en un entorno inferior antes de su implementación en producción.
En este estudio de pruebas, la principal aplicación de la automatización fue con el fin de simular las peticiones durante las pruebas de carga. Se ejecutaron varios flujos de trabajo con usuarios virtuales a escala con la capacidad de aplicarse a distintos tamaños de carga, como se ilustra en los resultados de las pruebas.
Se utilizaron scripts de Python para realizar análisis e identificar patrones en los tiempos de espera del servicio, el aprovechamiento del ArcSOC, los tiempos de respuesta y las solicitudes fallidas para informar de los cambios necesarios en el sistema. También se utilizaron scripts de Python, PowerShell y SQL para restaurar la base de datos a su estado original tras completar una prueba de carga.
Aunque la seguridad no fue el énfasis del estudio de prueba, es fundamental tener en cuenta los requisitos de seguridad en las primeras fases del proceso de diseño de cualquier sistema de producción. El software de ArcGIS ha sido diseñado para funcionar eficazmente dentro de redes seguras, incluidas las que están totalmente desconectadas de Internet. El diseño del estudio de prueba sí incluye el uso de un proveedor de identidades para proporcionar la autenticación y autorización adecuadas.
Recursos relacionados:
Aunque las integraciones no entraban en el ámbito del estudio de prueba, un sistema de administración de la información de red requiere con frecuencia la integración con otros sistemas de la empresa como los sistemas de gestión de activos empresariales (EAM), de gestión de relaciones con los clientes (CRM) y de gestión avanzada de la distribución (ADMS). Además de las consideraciones estándar de integración con ArcGIS, la funcionalidad ArcGIS Utility Network cuenta con requisitos adicionales que deben tenerse en cuenta. En función de los requisitos de integración, pueden admitirse otro tipo de API y/o SDK. Consulte Viaje a la red de servicios: Visión general de las integraciones para más información.