Arquitectura física

Esta arquitectura se ha diseñado con:

• Una compañía de gas pequeña-mediana en mente
• Soporte para flujos de trabajo con una carga de diseño objetivo de 15 editores de ArcGIS Pro y 200 usuarios web de ArcGIS (personas usuarias generales).
• Una geodatabase corporativa configurada con Microsoft SQL Server
• Infraestructura en la nube de AWS

El sistema se diseñó y probó para los flujos de trabajo especificados, con ajustes en los tipos y tamaños de equipo según fuera necesario en función de los resultados de las pruebas.

Descargue un archivo de Microsoft Visio de esta arquitectura.
Más información sobre recursos de diagramación para sistemas ArcGIS.

Tipos y tamaños de equipos

A continuación se representan los tamaños de equipo elegidos y validados para el ámbito y la finalidad de este estudio de prueba. Sin embargo, es muy recomendable seguir un proceso de diseño completo que tenga en cuenta sus necesidades empresariales y técnicas.

Esri ofrece servicios de diseño de arquitectura de sistemas en caso de que necesite ayuda para determinar todos los diferentes factores relacionados con el diseño físico de su organización, como las redes, el almacenamiento, los entornos de sistemas y el dimensionamiento. Los requisitos mínimos del sistema para cada componente figuran en la documentación del software correspondiente, disponible en línea.

Escritorio (ArcGIS Pro y navegador web)

• 3 equipos (utilizados en las pruebas)
• Tipo de instancia de g4DN.xlarge
• 2 CPU (4 vCPU)
• 16 GB RAM
• 16 GB DE GPU
• Disco de 128 GB

Portal for ArcGIS

• 2 equipos
• Tipo de instancia de m5.xlarge
• 2 CPU (4 vCPU)
• 16 GB RAM
• Disco de 128 GB

Servidor SIG de ArcGIS

• 2 equipos
• Tipo de instancia de m5.2xlarge
• 4 CPU (8 vCPU)
• 32 GB RAM
• Disco de 128 GB

ArcGIS Server (servidor de alojamiento)

• 2 equipos
• Tipo de instancia de m5.2xlarge
• 4 CPU (8 vCPU)
• 32 GB RAM
• Disco de 128 GB

ArcGIS Data Store (relacional)

• 2 equipos
• Tipo de instancia de m5.xlarge
• 2 CPU (4 vCPU)
• 16 GB RAM
• Disco de 256 GB

ArcGIS Web Adaptor

• 2 equipos
• Tipo de instancia de m5.large
• 1 CPU (2 vCPU)
• 8 GB RAM
• Disco de 128 GB

ArcGIS Monitor

• 1 equipo
• Tipo de instancia de m5.2xlarge
• 4 CPU (8 vCPU)
• 32 GB RAM
• Disco de 128 GB

Almacenamiento de archivos

• 1 instancia
• Rendimiento de 64 MB/s
• Disco de 1 TB

Base de datos

• 1 equipo
• Tipo de instancia de r5.2xlarge
• 4 CPU (8 vCPU)
• 64 GB RAM
• Disco de 256 GB

Servidor de dominio

• 1 equipo
• Tipo de instancia de m5.large
• 1 CPU (2 vCPU)
• 8 GB RAM
• Disco de 128 GB

Consideraciones adicionales sobre la infraestructura

A continuación se exponen otras áreas a tener en cuenta a la hora de diseñar un sistema de administración de información de red y una explicación de algunas de las opciones de infraestructura elegidas para este estudio de prueba.

Equilibrador de carga de aplicaciones (ALB)

En una implementación de ArcGIS Enterprise de alta disponibilidad se requiere al menos un equilibrador de carga de terceros, que manipula el tráfico de clientes hacia su portal y sitios de servidor, así como el tráfico interno entre los componentes del software. Aunque ArcGIS Web Adaptor se considera un equilibrador de carga, es insuficiente por sí solo para servir de equilibrador de carga en una configuración de alta disponibilidad. Por lo tanto, en este estudio de prueba se utilizó un equilibrador de carga de aplicaciones de Amazon Web Services (AWS).

Consideración de la base de datos

Para el alcance y los fines de este estudio de prueba, se optó por implementar SQL Server en un equipo virtual (EC2). Sin embargo, en función de sus necesidades, podría considerar la posibilidad de aprovechar un servicio de plataforma de base de datos como RDS (Amazon Relational Database Service) o SQL Managed Instance en un entorno Microsoft Azure.

Almacenamiento compartido

Para implementar correctamente una implementación de alta disponibilidad de ArcGIS Enterprise, los almacenes de configuración deben almacenarse en una ubicación compartida de alta disponibilidad. Esto garantiza que estos datos sigan siendo accesibles aunque falle un servidor, proporcionando un servicio ininterrumpido a los usuarios finales. Además, el almacenamiento compartido simplifica la administración de datos en una implementación con varios equipos y mejora la escalabilidad al centralizar el almacenamiento de datos y permitir su ampliación según sea necesario.

Componentes del sistema no incluidos en el diagrama

Tenga en cuenta que, aunque el software antivirus y los componentes de red de AWS no se ilustran en este diagrama, estaban presentes en el estudio de prueba.