Uipath Platform Environment setup

Help
, ,
1

Hi Folks,

I don’t have a much knowledge on UiPath environment setup, please could you help me regarding the Orchestrator server. We are installing the UiPath orchestrator on Aws environment, so how the auto-scaling works on this cloud. Does it supports ?

2

Maybe someone else could speak to it in more detail.

A few months back I set up a simple infrastructure for UiPath using AWS Cloudformation.

It consists of RDS for the SQL Server, an EC2 instance for Orchestrator (2018.3.1) Platform, and multiple EC2 instances for each robot, with a partially built custom AMIs for Orchestrator and Robot and a bit of Cfn-Init scripting for some of the software installation and environmental configuration changes.

Originally I did have a Network Load balancer in front of Orchestrator with the eventual plan to have a balanced node with Redis to keep the master and slaves in sync, but this complicated the deployment with Cloudformation due to the installation steps of Orchestrator and the changes required to make to set up the additional slave instances.

As we don’t currently have a need for additional nodes (Running very minimal robots at the moment), I removed the NLB and Redis from the design to meet timelines.

Out of curiosity, what is your scenario where you would want to have auto-scaling for the Orchestrator nodes and/or Robots?

From what I’ve learned so far, it would be a matter of creating some deployment/build scripts, probably prepare some custom AMIs (Either one for Master and one for the slaves, or a common AMI that would make the required configuration changes programmatically) to minimize the bootup time required by the auto-scaling group.

4 Likes
3

Thanks for your response.

We would like to use EC2 auto scaling for Orchestrator and Robots both, for robots it will work i know, but for orchestrator i don’t know if it will work or not. I want to auto scaling for HA.

I have one more query if you can help that will be great which is related to ElasticSearch (ES).
Suppose during the initial installation i don’t use ES, but can we transfer logs from SQL server to ES later. I think that is possible to do it using scripting (bulk upload) but not sure.

1 Like
4

I think technically it would be possible the challenges that I see (and this may be from the little time I’ve spent thinking about it) are:

Depending on how you want to prepare an EC2, create custom AMI manually or using something like Packer.io to configure as much as possible to reduce the initialisation of a new instance when it matters

Robots

  • Dynamically Add/Remove Machines/Robots on provisioning and terminating instances, straight forward, and a few ways to go about it
  • Still, need to add the robot to an Environment. Different scaling groups per environment perhaps? With a Minimum of 1 and increase the maximum as you need more.
  • I’ve thought about a job schedule monitor to scale down to 0 and spin something up 10-30 minutes before the scheduled job and shortly after a period of non-schedules, would be neat, mostly from a cost-saving perspective, if you’re running jobs 24/7, this would matter.

Orchestrator

  • Configuration differences between the master and slave would need to have separate AMIs for this or script the init to account for it depending on what is needed.
  • If cost isn’t a concern would it be worth placing in an auto-scaling group? Could spin up multiple instances in a cluster behind a load-balancer or separate clusters in a primary/secondary setup behind the LBs.
  • We only have 10 unattended robots, and not all of them are in use at this time, so having multiple nodes isn’t an immediate concern in the near future.

Re: Loading past logs into ES, I imagine is possible, haven’t used ES myself before but I don’t see why not! We use Splunk in its place as we already use Splunk across the organization.

We send out logs Robot > Orchestrator, NLog is configured to direct to SQL and a file (JSON format), CloudWatch monitors the logs (File, and Event Viewer), which in turn is subscribed to Firehose. Firehose sends the logs over to a Lambda (Node.js) which transforms the events into a format accepted by a Splunk HEC, sends it back to Firehose which then sends it over to Splunk.

There is an NLog plugin for Splunk that would simplify this, but I haven’t tested it and by using Firehose if we ever decide to move away from Splunk, it would be a simple adjustment at one point in the chain to make.

+-------+    +------------+
| Robot +--->+Orchestrator|
+-------+    +------------+  +------+       +----------+
                     |NLog+->+ FILE <------->CloudWatch|
                     +-+--+  +------+       +-----+----+
                       |                          |
                       |                          |
                       |                     +----v---+          +------+
                       v                     |Firehose+---------->Splunk|
               +----------+                  +----^---+          |  HEC |
               |SQL Server|                       |              +------+
               |   RDS    |                       |
               +----------+                   +---v--+
                                              |Lambda|
                                              +------+
6 Likes
5

@codemonkee - Thanks for these details. I had a question on how the robot licensing works when the robots are auto-scaled? How do you register/deregister the bots from Orchestrator so that the available licenses are used appropriately?

2 Likes
6

I would defer to the documentation or support to talk about licensing. But there is no difference between manually spinning up a Robot or using Auto-scaling in terms of licensing, it just how you’re turning up the host and managing your robot service.

We leverage the Orchestrator API, so far have only implemented the Registration of a machine and robot upon creation of a new host. So it’s a two-part process, one is running the uirobot.exe with the connectstring parameter which we handle during the cfn-init step of our Cloudformation, and the other piece is to call the API to create a machine and create a robot record which we have worked into the pipeline via Powershell during the Robot stack creation.

We still need to work out the deregistration process, which includes removing the Robot and Machine record from Orchestrator as well as the host from the domain upon termination, but it’s not a priority at the moment and we’ve only had to do it once manually.

https://orchestrator.uipath.com/v2018.4/reference#api-references
https://platform.uipath.com/swagger/

5 Likes
7

Hi Twhitehead,

Can you please help me in configuring splunk with orchestrator.
How we can monitor real time logs of orchestrator using splunk?

8

Hi @shweta_B,

I’m happy to try and answer any questions that you may have, but I would ask that you post a new question/thread so not to be off-topic to the original post of this one.

Feel free to ping or PM me the new post.

Cheers,
Tim

10

Hi @Aman_Mongar

I’m happy to try and answer any questions that you may have, but I would ask that you post a new question/thread so not to be off-topic to the original post of this one.

Feel free to ping or PM me the new post.

Cheers,
Tim

11

Hey Whitehad, Is is possible to share the cloudfromation template for the stack that have Orchestrator, Robot and NLB (remove sensitive information from cfn if any). plz plz

12

Hi Tan,

I think in their essence the templates are pretty basic templates if you have some familiarity with the CF Template Anatomy.

  • Parameters: We include input parameters for
    • Environment [dev, preprod, prod]
    • CIDR blocks. Used to a couple of spots to reference our on-prem and other subnets in firewall rules, etc.
  • Mappings
    We use mappings for such references as the AMI that will be used and to define Environment specific properties
  • Conditions
    To be used in control flows such as how an instance is named or to enable/disable monitoring, multi-az mode for RDS for example.
  • Resources
    Define all your awesome resources! This is the only required part of the CF Template.
  • Outputs
    All our templates have outputs, some are just for an easy place to reference values like a URL, or ARN, and others are exported so that the resource (e.g. Roles/Policies, Security Groups, etc.) can be referenced in other stacks.

I haven’t really touched the templates since last year, made a few modifications here and there, but they are by no means complete or ideal so I do have to refresh my mind from time to time. I strongly recommend combing over the AWS documentation, they are pretty granular in their details and a good reference.

  1. Base Orchestrator / Robot
    Because of our restriction to only provision resources via CF, we have two templates that define a “base” EC2 instance which we then use to create a modified AMI. This is primarily to reduce the time it takes to spin up a new EC2 instance.

    In both cases, the AWS::EC2::Instance is pretty basic and defines minimal properties: Tags, ImageId, InstanceType, those sorts of things.

    Some pieces of interest might be the UserData and Metadata (AWS::CloudFormation::Init), with these you can script some of your initial configurations during initialization such as installing required packages or downloading required assets that are common to each Orchestrator or Robot instance, configuring firewalls, Enabling Roles and Features, UiPath etc.

    This is one of several ways that you could go about doing this. You could also choose to perform these steps with Systems Manager (SSM) or a combination of the two. I’ve also considered looking at Packer.io, but haven’t gotten there yet.

  2. Prerequisites
    This stack largely defines the resources that are common to the other stacks such as:

    And so on.

  3. RDS / SQL Server
    We use RDS for our SQL Server, but you can just as easily use another EC2 instance with SQL Server Installed on it or I believe there is a specific AMI for Windows/SQL Server. You’ll want to research and weigh the pros and cons to each model for your scenario.

    Again this is straight forward in terms of default properties of the resources

    • AWS::RDS::OptionGroup - We recently added in a specific option group to allow for a native SQL Server Backup and Restore
    • AWS::Route53::RecordSetGroup - To provide a friendly DNS name to the RDS instance
    • AWS::RDS::DBInstance - I suggest reading through all the properties and see what’ll you’ll need, I think it would good to put some thought into AllocatedStorage, MultiAZ, StorageType (I recommend making this one gp2 (General Purpose SSD) opposed to Standard (Magnetic) as the Magnetic storage cannot be expanded without replacing the instance causing downtime, learned that the hard way not realizing it defaulted to standard at the time that we first created the instance.

  4. Orchestrator Service
    This is very much dependent on your needs, for example we don’t currently have High-Availability for Orchestrator (Multiple Nodes, with Redis to keep them in Sync). This template is similar to the base, but extends it with items that we didn’t want to or hadn’t thought out the workflow yet to pre-configure it during the base AMI creation.

    • DNS for a friendly URL
    • Import of Certificate and Key
    • CloudWatch Agent and Configuration (We use it to collect logs to ship to Firehose and over to Splunk)
    • UiPath Orchestrator install - Because the installer creates the database, we haven’t separated pre-installed Orchestrator in the base AMI, this is defined with command line parameters and manually initiated using the cfn-init command.
    • Binding DNS to IIS
    • UiPath Web.Config modifications such as enabling Windows Authentication
    • Importing Domain SG/Users to Orchestrator
    • Adding Domain SG/Users to local RDP groups

      Note: some of these settings that we configure in the base AMI and during the Orchestrator spin up we could pull out of Metadata and create a Group Policy as we join our hosts to the domain, which is shrinking the templates a little bit
      e.g Securit Groups, IE Enhanced Security, Trusted Sites and so on.

  5. Robot Service
    Right now, we have a 1 machine/host for each Robot/AD Process Account, but could just as easily enable “High Density” mode but enabling the RDS Host Feature and applying the appropriate CAL.

    Not much different here, most of the setup happened during the Base Robot AMI creation, here we will enable the UiRobot Service and also register the Robot to Orchestrator using the connection string.

    We then manually create a machine robot record in Orchestrator, but you could easily automate this using the Orchestator API, or if you are running 2019.10 auto provision robots in the modern folders for Studio and Attended.

  6. Monitoring
    I won’t go into a lot of detail on this one as I think it is more unique to our situation and there are many ways to go about it from your own Orchestrator/Elastic Search to your own solutions, Cloudwatch, Splunk, and so on - and directing those logs is easily done through the NLog configuration for Orchestator and the Robots.

  7. Network Load-balancer
    We actually don’t make use of a NLB at the moment, I tried last year but was running into some troubles and haven’t revisited yet. We will have to when we introduce HA to our design.

    High level, you’d want to Create your NLB (AWS::ElasticLoadBalancingV2::LoadBalancer), with a DNS Record then as part of your Orchestrator template create some Target Groups (AWS::ElasticLoadBalancingV2::TargetGroup) and Listeners (AWS::ElasticLoadBalancingV2::Listener)

There are so many different ways to tackle the problem within those ways, a lot of different needs for each individual or organization. How you will handle your build pipeline for deployment and upgrades and logic around certain pieces like backup and recovery, or you might consider using something like Teraform instead of raw CloudFormation.

I’m not sure how long you’ve been using UiPath, AWS, or Cloudformation for - but if you are fairly new to any of them, my approach would be to familiarize yourself with the basic of each, do some piece manually e.g. Spin up a EC2 instance through the Web Console or CLI and then manually install UiPath and components, identify what has to be done where and what order and then translate those steps into CloudFormation, SSM Documents and so on. I find once I had the basics of AWS to know what common services are available and how they work, it was much easier to translate that to CloudFormation after reading the documentation and often referencing it as I am building the templates.

There are tons of guides, template samples, tutorials and so on provided by Amazon in their documentation and many other resources across the Internet that would be much more helpful than trying to cram all the variable possibilities into a single post without knowing your requirements.

I believe we can be more helpful when presented with a specific problem or question that you might be having troubles with as that is more tangible and easier to address using your best judgement on whether it fits within the OP of this topic or if it would be better suited in a new topic to address your specific problem/question.

3 Likes
13

Not sure if it is really need for auto-scaling as 1xM4.4xlarge should be sufficient for 500 robots. with HA design it can goes upto 1000+ robots.

Auto scaling wise you will need to provision orchestrator and some modification on its connection back to the RDS and HA node parts.