High availability for microservices

In a distributed Teamcenter production environment, ensure high availability by configuring redundant microservice node servers and service instances. For detailed deployment examples and sample configurations, see Teamcenter Deployment Reference Architecture, available from the Teamcenter documentation and also from the Teamcenter Downloads area on Support Center. Capacity With the many variables affecting a Teamcenter environment, no simple formula exists that can prescribe the precise combination of microservice nodes and microservice instances. As with all server-side deployments, monitor the consumption of CPU and memory on each microservice node. If you observe resource contention, you can increase resources for microservice execution by deploying additional microservice nodes and services running on additional hardware. Failover Windows Achieving failover capability on Windows requires that a service registry, a service dispatcher, and instances of all microservices must each be running on at least two nodes. By default, an instance of the service registry and service dispatcher run on the master node; additional instances can be running on any worker nodes. When installing microservice nodes through , be sure to list all instances of the service registry and the service dispatcher. Docker Swarm Achieving failover capability with Docker Swarm on Linux requires that an odd number of servers be joined to the swarm as managers, typically three or five. This helps the Docker swarm effectively manage the swarm by majority vote. Any number of servers can be joined to the swarm as workers. Kubernetes Control Plane Follow the vendor documentation. If using a cloud provider, the provider typically provides a Control Plane with failover. Microservice nodes To avoid a single point of failure, in on-site deployments implement at least two microservice nodes. Ensure that these nodes are allocated on different physical hardware. Allocate at least two replicas of every component to avoid a single point of failure. For nodes in cloud deployments, to avoid location-specific outages, ensure that the nodes are spread across different failure zones (such as AWS Availability Zones). The exception to replicating components is the Service Registry. A single Service Registry is sufficient. This is because in the event that the Service Registry (Eureka) container goes down, the Eureka Client Cache provides needed information during the brief period of time that passes while the container manager brings back up the container. If possible, test for node failure conditions and validate that client requests are handled using service load balancing. Ensure desired scale once the nodes are recovered. For backup options, consult the vendor documentation. Example microservice deployment topologies for high availability In a high availability configuration, where there is more than one File Repository microservice deployed, with the File Repository storage shared between the multiple instances of File Repository, the Active Workspace publish operation needs to be performed only once, from one of the nodes (preferably the primary node). This updates the shared storage of the File Repository microservice, so the publish does not need to be repeated from another node. Any new publish will overwrite the previous publish in the shared storage. Additionally, the publish should always be done from the same node (for example, the primary node) as used for the previous publish. It is not recommended to publish from a different node in a subsequent publish, as this may cause errors.