On-prem UiPath Orchestrator

Learning about UiPath Orchestrator’s inner details is mandatory for any successful UiPath support and administration professional. If Orchestrator is installed on-prem, it is even more important to learn about it. There are two ways Orchestrator can be configured:

• Single node setup – One instance of UiPath Orchestrator is installed
• Multi-node setup – Multiple instances of UiPath Orchestrator are installed

Before Patty can start the actual installation, she must understand the underlying architecture of these two options.

Let’s see them in detail in the next section.

Single node UiPath Orchestrator architecture

As the name suggests, a single node will have Orchestrator installed in one instance. As per UiPath documentation, a single node can support small or medium-scale deployment of Robots (i.e., 1 - 250 unattended Robots or 1 - 2,500 attended Robots). There is no failover plan, hence downtime is expected during maintenance windows or server outages.

This is the preferred model for any proof of concept and pilot run since the time and cost to set this up are low:

Figure 1.2 – UiPath single node architecture

Components list

• UiPath Orchestrator: It is recommended to install the Orchestrator application on a Windows server (physical or virtual). It will be a web application accessible from the Internet Information Services (IIS).
• SQL database (DB): A SQL database is recommended to be set up in a separate SQL Server, or you can even leverage the cloud services provided by popular cloud service providers. This database will be the primary application database where the data can be queried later after installation. The connection must always be alive between the DB and UiPath Orchestrator.
• UiPath Robots (digital workers): This software is set up in virtual or physical machines that can be remotely accessed by Robot accounts. Multiple devices can be registered and connected with Orchestrator to execute the automation.
• Elasticsearch (ES) and Kibana (optional): Orchestrator logs can be directed to the SQL DB and ES. Hence, ES is an optional setup. ES and Kibana can be set up on the same Orchestrator Windows server or a separate server based on the need. ES is an open source application that can optimize UiPath Orchestrator logs access from Orchestrator. We can redirect the execution logs away from default DB tables and into the ES indexes by updating the information in UiPath.Orchestrator.dll.config. Kibana is an optional open source monitoring dashboard application that can also be installed on this server for monitoring needs.

ES and Kibana are part of Elastic Stack, and you can learn more about Elastic Stack here: https://www.elastic.co/elastic-stack/features.

Note

UiPath Insights is the official business analytics and monitoring tool offering from UiPath. It provides complete monitoring and alerting capabilities for a UiPath program. This product can also be installed when we set up the Orchestrator nodes. If Insights is in use then ES does not need to be set up.

Patty has gathered enough knowledge to set up a single node Orchestrator now.

Note

Please refer to the software requirements to install the supported version of the software from here: https://docs.uipath.com/installation-and-upgrade/docs/orchestrator-software-requirements.

Multi-node UiPath Orchestrator architecture

As the name suggests, multi-node will have multiple instances of Orchestrator installed. UiPath documentation can support large-scale UiPath Robot deployments with better performance and fault tolerance, as multiple Orchestrator nodes are available. If one node fails, other nodes will process the transactions and bots.

In addition, horizontal scalability is possible as we can add additional nodes to the Orchestrator as the Robot needs increase. Starting with two Orchestrator nodes that support up to 7,000 Robots, we can scale to 15 Orchestrator nodes, where we can have 150,000 Robots on the platform.

Patty and her team can start building a single Orchestrator instance. Then, as they harden things up for production, they can move ES off the single server, add additional DB server ES shards, and bring up a second node as an active/standby configuration. In other words, single to multi-node is more of a progression for any organization who are willing to mature their automation journey.

Figure 1.3 – UiPath multi-node architecture

Let’s look at the components one by one:

• UiPath Orchestrator scale set: It is recommended to install the individual Orchestrator applications on a dedicated Windows server(s). All the Orchestrator nodes should have a similar IIS configuration, access rights, and security policies. It is recommended to have a service windows user account configured to this UiPath Orchestrator scale set. This can be used to set up the DB connection.
• Scalable SQL DB: The database server should be configured based on the number of Orchestrator nodes in production. Most cloud DBs are now scalable, and it would be good to consult the DB administrator to set up the best practices and proper access privileges.

DB maintenance activities need to be put in place from day one because the performance of Orchestrator is directly related to DB health.

• UiPath Robots (digital workers) run environment: These are set up in virtual or physical machines, which can be remotely accessed by Robot accounts. The only difference here is that this environment should be set up to scale faster to accommodate the new Robots quickly. A Kubernetes container is a popular option recently in this environment.
• ES cluster environment: It is recommended to set up a separate Windows server and host the ES and Kibana applications to build this cluster. The main idea is to have a scalable option when the Robots’ logs start to increase with the Robots’ jobs being executed. Logs are critical to maintaining UiPath operational health, and hence maintaining this cluster is crucial to support and monitor.
• High Availability Add-on (HAA) cluster environment: HA provides redundancy and stability for your multi-node Orchestrator deployment through failure resistance. In an HAA configuration, as long as multiple Orchestrator and HAA nodes are available, the other nodes will be activated if one fails; if any nodes fail or are taken down on purpose, processing will “failover” to the rest of the nodes in the cluster. Moreover, horizontal scalability is also possible that means you can add another node whenever your Robot counts needs to grow. UiPath HAA is just Redis Original Equipment Manufacturer (OEM) version for UiPath. Redis is used for in-memory data structure storing used for caching, which will improve the application’s performance. The UiPath support contract supports only the multi-node setup with UiPath HAA. Hence, it is more than a nice-to-have component. Although there are other ways to set up multi-node failover and horizontal scaling, UiPath HAA is the only method supported by UiPath.

Please refer to the documentation for setup: https://docs.uipath.com/installation-and-upgrade/docs/haa-installation.

• Load balancer (LB): A load balancer is an appliance (which encompasses hardware load balancers, such as F5, as well as software load balancers) that will automatically distribute incoming web traffic across various endpoints. All the cloud service providers have a load balancer offering that can be leveraged, for example, F5 load balancing on AWS. UiPath Orchestrator supports Layer 4 load balancing only, not Layer 7, and no SSL offloading:
  • LB for Orchestrator servers: Load balancers are critical to redirect traffic to different Orchestrator nodes originating from various client requests. It is recommended to have a load balancer URL for Orchestrator login so if a node is down, we can still access the application.
  • LB for ES servers: The same concept applies to redirect connections from Orchestrator to ES servers. If there are multiple ES servers, then a load balancer is functional. There can also be scenarios where there are numerous ES shards on several different servers without a load balancer.
• UiPath Identity server: This provides a centralized authentication service to all UiPath products, and it is included in the on-prem Orchestrator installer. It is recommended that the enterprise Identity and Access Management (IAM) team configure the Identity server component to meet the existing enterprise standards. Most of the configurations are done on appsettings.json (please refer to https://docs.uipath.com/installation-and-upgrade/docs/orchestrator-is-appsettings-json).

The recommended hardware setting for scaling up the operation is mentioned here: https://docs.uipath.com/installation-and-upgrade/docs/orchestrator-hardware-requirements.

Note

NuGet packages are stored in a shared location that all the Orchestrator nodes can access. SQL Server will have redundancy and have the Always-on Availability group. If UiPath Insights is used, it is good to have an Insights application server added to this architecture.

Please refer to this link for hardware requirements based on the number of Robots in production: https://docs.uipath.com/installation-and-upgrade/docs/orchestrator-hardware-requirements.

I hope this was interesting. Patty and her team know to set up a multi-node Orchestrator in their organization. Now, let’s look at the Orchestrator setup details in the next section.

Orchestrator setup

As introduced in the previous section, UiPath Orchestrator is the critical component used for the creation, monitoring, and deployment of Robots in the defined runtime environments.

There are three main options of UiPath Orchestrator setup possible in an enterprise:

• The first one is a standalone installation which can be on-prem or cloud
• The second one is the UiPath Automation Cloud
• The third option is to set up the UiPath Automation Suite (starting November 2021)

It is important for UiPath Support and Administrator professionals to overview the UiPath Orchestrator setup. Let’s start with this setup of a single node on-prem Orchestrator.

On-prem UiPath Orchestrator (single node)

Patty can now proceed with the installation detailed in this section. On a high level, the UiPath Orchestrator setup can be charted down into five different steps, as shown in the following diagram:

Figure 1.4 – UiPath single node setup steps

All five steps are discussed in this section; lets start with the first step:

1. Set up a Windows Server on a machine or a cloud infrastructure. Ensure this web application server configuration (CPU, memory and security groups, and so on) is set up as per the recommendation from the UiPath documentation.

Refer to this link for more information: https://docs.uipath.com/installation-and-upgrade/docs/orchestrator-hardware-requirements.

2. Configure a SQL server and set up a DB. The next important step is to set up the DB server. Again, this can be set up on a separate machine or subscribed as a cloud service. Once the server is set up, ensure the DB is created and credentials noted.
3. Install and set up the prerequisites. The prerequisites (URL Rewrite, .NET, certificates, and so on) need to be installed on the application server before starting the UiPath Orchestrator setup. Please refer to the complete checklist from this link: https://docs.uipath.com/installation-and-upgrade/docs/orchestrator-prerequisites-for-installation.
4. Install UiPath Orchestrator; this is the primary step of running the UiPath Orchestrator installer and updating the mandatory information such as the DB information, Identity server, certificate, and so on). The installation will be completed successfully when all the prerequisites and access are correctly configured. Otherwise, the installer will roll back the installation.
5. Verify the UiPath Orchestrator installation and active license. The last step is to verify the installation by logging into Orchestrator and activating the license.

Note

The ES server setup mentioned in the architecture diagram is optional, and we will cover it in a different chapter. Please refer to Setting up On-Prem UiPath Orchestrator in AWS EC2 in the book's GitHub repository (https://github.com/PacktPublishing/UiPath-Administration-and-Support-Guide) to get a step-by-step walkthrough of this setup.

Next, let’s look at some of the essential considerations for a multi-node setup for Patty and her team.

Multi-node on-prem Orchestrator considerations

Based on the customer’s need, a multi-node setup can be made. In the case of Patty and her team, once a single node orchestrator was set up, they decided to add more nodes and grow into a multi-node resilient platform. Multi-node setup is the most common Orchestrator setup in any organization that is still using an on-prem environment. A two- or three-node setup is typical for mid to large-scale Robot setups. There are a few considerations to set up this environment:

• The Orchestrator setup needs to replicate to Orchestrator cluster setup. Multiple servers will act as nodes for UiPath Orchestrator. Single node setup can be scaled to multi-node with appropriate infrastructure if needed.
• Similarly, the ES setup needs to be scaled up to the ES cluster environment. Multiple ES servers may need to be set up to support the scaling needs of Robots.
• SQL servers need to be configured to be scalable and available. It is recommended to have a redundancy setup in effect for the servers.
• In-memory HAA clusters need to be configured in the multi-node setup to maintain the platform’s performance.
• Load balancers need to be configured to redirect traffic to Orchestrator, and an additional load balancer is recommended if there is an ES cluster setup.
• The Robots farm needs to be set up to scale up operations on demand.

The entire setup can be made on physical machines or cloud infrastructure based on companies’ IT policies. After following the steps, Patty and her team set up multi-node Orchestrator.