The aan deployment topology is flexible and can be deployed in single-node or multiple-node configurations.
API Portaldeployment topology is flexible and can be deployed in single-node or multiple-node configurations.
The following graphic is the deployment topology for
The following table summarizes various topology sizes and their typical use cases:
Number of Nodes
Low traffic or test environments
In a single-node deployment topology, a single Docker Swarm cluster with a single Docker Swarm Manager node is running the
API Portalapplication. The topology does not offer any fault tolerance. If the node fails for any reason, there may be production downtime and data loss.
A multi-node deployment has the following requirements:
- All systems in the Docker Swarm must be able to communicate with each other. Systems that are spread across multiple data centers must also be able to communicate with each other. The network latency between the systems should be low.
- The Docker Swarm cluster resides in a trusted zone in each data center and is not exposed publicly.
- Docker Swarm manager nodesmusthave static IP addresses.See https://docs.docker.com/engine/swarm/admin_guide/#configure-the-manager-to-advertise-on-a-static-ip-address for more information about static IP addresses.
In a three-node deployment topology, the one Manager node runs only the dispatcher service. The two worker nodes runs the rest of the services for
API Portaland CA Jarvis Analytics Engine. This scenario increases processing capabilities because the services are load balanced by your global load balancer or by DNS round-robin at the DNS server. When traffic reaches the Docker Swarm Manager node, further service load balancing is achieved by an internal application load balancer.