Best practices for system architecture

When deploying ArcGIS GeoEvent Server, it is important to design and plan a system architecture specific to your real-time visualization and analytics use cases. This includes the hardware and software components and the connections between them. It also includes a human element; the people who will work on the system, access requirements they require, and the best practices they must follow to keep the system running optimally.

Ultimately, you are deploying GeoEvent Server to ingest, analyze, and disseminate real-time and big data content to end users in ways that enable organizational workflows that lead to better and more informed decisions. Your deployment needs to be designed to ensure its integrity across all these varying workflows and use cases.

Real-time visualization and analytic workflows often involve supporting multiple data feeds with differing analysis requirements. Each workflow typically has a different impact on system resources. With this level of flexibility, it is important to define your specific workflows and use cases in the planning phase and build a system that meets those requirements.

The best practices below can help you plan, design, and deploy a system architecture with effective strategies for operational performance and reliability.

Environment isolation

The system that hosts GeoEvent Server in production should be in a separate environment from the development and testing systems. This practice is known as environment isolation; it reduces the risks of unintended updates or deletions of the real-time services your end users depend upon.

Development, staging, and production

A common model for environment isolation contains three tiers: development, staging, and production. Implementing a minimum of these three tiers is best practice and depending on your development and testing practices, you may require additional tiers.

In a development environment, GeoEvent Server administrators can work on developing and implementing new real-time services without impacting end users. This dedicated server environment is typically used for unit testing, creating new event processing workflows, and creating and deploying new workflows and capabilities. The size and complexity of the environment depends on the level of risk generated by changes, the number of content creators, and the potential impact of system outages and downtime.

A staging environment, of which there can be multiple, is isolated from the production environment but mirrors that environment as closely as possible. This assures any issues with the system and real-time services are detected prior to being deployed to production. For example, if you are tracking vehicle locations and alerting when a service vehicle enters a facility, the staging environment should replicate that identical workflow. As a best practice, always test software, apps, configurations, and networks in the staging environment prior to deploying to production.

A production environment is the system that provides your end users the real-time layers, maps, and apps that support organizational workflows. You may have service-level agreements (SLAs) that define the acceptable level of downtime. Availability of a production environment should be constantly monitored and appropriate methods of downtime prevention such as backups and standby machines should be considered.

See High availability in ArcGIS Server, ArcGIS Enterprise, and the GeoEvent Server Deploy section for more information.

Syncing GeoEvent Server configurations

A configuration of GeoEvent Server in a tiered system can be managed in one of two ways, either required changes are manually updated on each tier or a GeoEvent Server configuration file can be used. While the manual approach is a viable method, exporting and importing configurations of GeoEvent Server is the easiest way to update different tiers.

Couple things to note, configuration files are text files formatted in XML that can be edited in a text editor if key strings need to be updated such as server names. Also, when importing a GeoEvent Server configuration file, you have the option to perform a selective import which has two advantages. The first is that you can choose to import only the components that were updated which can reduce the impact on a target configuration. Second, any issues related to the newly imported configuration will be isolated to those changes and troubleshooting can be isolated.

As a best practice, you should always create a backup of the tier’s configuration before importing any new configuration. This ensures you can always revert to the previous configuration if necessary. GeoEvent Server creates automatic backups on a nightly basis by default, but as a best practice export a configuration prior to importing a new configuration.

For more on managing configurations, see Configurations.

Load balancing

Load balancers can take an intermediate position between clients and servers for both incoming and outgoing event feeds. They identify and accept communications and pass them to the correct recipient, distributing the client’s workload across the available computing resources. In doing so, load balancers improve server security, balance system usage, and simplify service delivery.

GeoEvent Server cannot utilize ArcGIS Web Adaptor as an incoming event feed load balancer. Other third-party technologies should be utilized when load balancing a GeoEvent Server deployment. Unfortunately, the nature of the event feeds themselves dictate the load balancing strategy that must be deployed.

For more information about these strategies, see GeoEvent Server scalability & reliability.

For outgoing event feeds, standard third-party load balancers can be utilized to spread the event load across targeted servers. If the target system is ArcGIS Enterprise, ArcGIS Web Adaptor combined with a multiple-machine GIS server site can be utilized to improve scalability and reliability.

ArcGIS Web Adaptor instances distribute incoming requests to multiple-machine ArcGIS Server sites using a round-robin pattern. Including ArcGIS Web Adaptor instances in your deployment is recommended for simple configurations.

More advanced configurations of GeoEvent Server can benefit from using a third-party load balancer. These components allow you to utilize custom logic (distributing requests in a pattern versus round-robin), manage asymmetric loads, and provide additional security measures such as reverse proxies. Using a third-party load balancer can help your organization address advanced business and technical requirements.

As a best practice, you should always use at least one load balancer in your ArcGIS Enterprise deployment, whether it is ArcGIS Web Adaptor or a third-party component. Using load balancers helps to limit the number of points of entry to the system, hiding the internal topology of the network and simplifying operations.

Workload separation

Your organization may have multiple teams defining different types of work in a GeoEvent Server deployment. The resource requirements for each, and the expectations or contracts that govern their work, are often different. For example, one event feed that displays large spikes in event volume consuming public requests may need occasional access to powerful resources, while a steady event feed tracking a fleet of vehicles may need constant access to less-intensive maps and apps.

During the planning phase of a GeoEvent Server deployment, identify the needs and usage patterns of each event feed that will be implemented in your system. Then, allocate your real-time event processing workload to appropriate server resources and isolate the different real-time services based on their resource usage.

When you separate the workloads of your organization’s various real-time services, the work done by one set of services will not affect the resources available to another set of services. This is important when SLA’s govern some or all your organization’s real-time GIS operations. If you are under an obligation to provide users with a certain level of availability, isolating machine resources reduces the risk each teams work will affect other resources.

Techniques for workload separation

Workload separation is commonly done by deploying multiple GeoEvent Server machines side-by-side. Each GeoEvent Server machine is then dedicated to serving specific use cases or working with certain event feeds with similar requirements.

When multiple GeoEvent Server machines are deployed, event data can be sent to different machines by either configuring real-time services on each GeoEvent Server machine or by utilizing event routing technology such as a load balancer that distributes event data based on the type or source of the event data or workflow. This effectively reduces resource contention among your different machines. For example, maybe one GeoEvent Server machine receives vehicle location data and performs necessary real-time analysis, while another receives and manages all citizen requests for assistance. In this example, your organization’s vehicle location tracking workflows will not be affected by an influx of citizen requests that could be submitted during a large weather event. Using a load balancer to manage your data feeds provides flexibility and control of the event data and in turn promotes system stability. One drawback of using load balancers is they increase the complexity of the system architecture and require additional tools and skills to configure and maintain.

Deploying multiple GeoEvent Server machines for workload separation allows you to assign machines with varying resources to different event feeds. This can be useful when the event processing performed on one feed is more compute-intensive than on another feed.