Déploiement dans le cloud (Deployment in the Cloud)

Plusieurs options de déploiement du cloud d'entreprise sont disponibles pour héberger Orchestrator, telles qu'Amazon Web Services (AWS), Microsoft Azure ou Google Cloud Platform (GCP). Nous détaillons ici un grand déploiement évolutif utilisant les offres Azure Infrastructure as a Service (IaaS). Les services suivants sont requis :

• Ensemble de disponibilité de machine virtuelle pour Orchestrator
• Groupe de machines virtuelles à haute disponibilité pour Elasticsearch
• Azure SQL Server
• Azure Load Balancer
• Cache Redis Azure pour les déploiements multinœud
• Service DNS distribué (tel que Cloudflare)

Architecture

Remarque :

Les exemples d'architecture ci-dessous contiennent des composants facultatifs et/ou différents (par exemple : CyberArk, module complémentaire haute disponibilité UiPath).

La Jumpbox illustrée n'est pas obligatoire mais constitue une bonne pratique d'isolation et de sécurité des données à suivre dans vos environnements de production.

Architecture à nœud unique

Architecture multinœud

Prérequis matériels

Cette section décrit les configurations matérielles utilisées pour les tests de performances répertoriés dans la section Montée en charge de votre déploiement, ci-dessous.

Nœuds Orchestrator

Chaque nœud Orchestrator doit être configuré comme suit :

VCPUs	RAM (Go)	SSD (GB)
16	32	128

SQL Server

Les spécifications de la machine virtuelle SQL Server doivent évoluer en fonction du nombre de nœuds Orchestrator :

Nœuds Orchestrator	VCPUs	RAM (Go)
1-2	8	16
5	16	32
10	16	64

Groupe à haute disponibilité Elasticsearch

Le groupe à haute disponibilité Elasticsearch comprend 3 nœuds principaux et 6 nœuds de données, pour un total de 9 nœuds, chacun contenant les spécifications suivantes :

VCPUs	RAM (Go)	OS SSD (GB)	Data SSD (TB)
8	16	128 (avec 5 000 E/S par seconde et un débit de 100 Mo/s)	1 (avec 5 000 E/S par seconde et un débit de 200 Mo/s)

Prérequis logiciels

Logiciels	Version
Système d'exploitation	Windows Server 2016
Bases de données	SQL Server 2017
Journalisation	Elasticsearch 6.4.0

Les versions répertoriées ci-dessus sont celles utilisées pour les déploiements et les charges testées en termes de performances décrites. Pour toutes les versions compatibles avec Orchestrator, cliquez ici.

Équilibrage de charge

Pour les déploiements multinœud, il est recommandé d'utiliser deux équilibreurs de charge Azure Standard :

• Un pour les serveurs Orchestrator ;
• Un pour les serveurs Elasticsearch.

Azure Redis Cache

Important :

Les déploiements d'Orchestrator multinœud utilisent le protocole RESP (REdis Serialization Protocol) pour la communication et peuvent donc être configurés à l'aide de n'importe quelle solution mettant en œuvre ce protocole, telle que le cache Redis Azure dans cet exemple.

Les déploiements haute disponibilité d'Orchestrator ne sont pris en charge par UiPath que si le module complémentaire haute disponibilité UiPath est utilisé.

Pour les déploiements multinœud, il est recommandé d'utiliser deux instances Redis distinctes :

• Cache Redis Azure de niveau Premium avec un cache de 6 Go : nœud principal utilisé pour l'état de la session et les associations utilisateur-entité ;
• Cache Redis Azure de niveau de base : utilisé pour monter en charge le service SignalR.

Configuration

Paramètres UiPath.Orchestrator.dll.config

1. Définissez tous les nœuds Orchestrator pour qu'ils effectuent le rapport à Elasticsearch au lieu de leur journal des événements Windows respectif en définissant le paramètre writeTo dans l'index serverdiagnostics comme suit :

   <logger name="*" minlevel="Warn" writeTo="serverElasticBuffer"/>

2. Activez la mise en cluster des exécutions Quartz comme suit :

   <add key="quartz.jobStore.clustered" value="true" />

3. Dans la section Déploiement, configurez le référentiel NuGet comme suit :

   <add key="NuGet.Repository.Type" value="Composite" />
   <add key="Deployment.Libraries.AllowTenantPublish" value="true" />
   <add key="Processes.AllowUpdateWithRunningJobs" value="true" />

4. Dans la section Équilibreur de charge, configurez les instances de Redis comme suit, en veillant à remplacer la chaîne de connexion et le mot de passe par vos valeurs correspondantes :

   <add key="LoadBalancer.UseSqlServer" value="false"/>
   <add key="LoadBalancer.UseRedis" value="true"/>
   <add key="LoadBalancer.Redis.ConnectionString" value="<your.redis.cache.windows.net>:6379,password=****"/>
   <add key="LoadBalancer.SignalR.UseRedisScaleout" value="true"/>
   <add key="LoadBalancer.SignalR.RedisScaleout.ConnectionString" value="<your.second.Redis.Server>:6379,password=********"/>

5. Définissez Max Pool Size dans la chaîne de connexion à la base de données comme suit :

   <add connectionString="Data Source=172.16.100.12;Initial Catalog=UiPath;User ID=admin;Password=*******;Max Pool Size=700" name="Default" providerName="System.Data.SqlClient" />

   Remarque : veillez à remplacer les paramètres Data Source, Initial Catalog, User ID et Password par les valeurs respectives de votre service Azure Orchestrator. Voir ici pour plus de détails.
6. Définissez la taille du tampon Elasticsearch comme suit :

   <target name="robotElasticBuffer" xsi:type="BufferingWrapper" bufferSize="1000" flushTimeout="5000">

Montée en charge de votre déploiement

Le nombre de nœuds nécessaires dans votre groupe identique Orchestrator dépend du nombre de robots déployés :

Nœuds de groupe identique d'Orchestrator	Nombre de Robots
1	jusqu'à 4 000
2	jusqu'à 8 000
5	jusqu'à 24 000
10	jusqu'à 48 000

Ces déploiements ont été testés à l'aide des configurations matérielles et logicielles ci-dessus pour ne présenter aucune perte de performances sous la charge spécifiée ci-dessous.

Tests de performances

Données statiques

Les données statiques font référence à la charge initiale d'Orchestrator existante.

Entité	Un seul nœud	Deux nœuds	Cinq nœuds	Dix nœuds
Tenants	40	80	240	480
Environnements (Environments)	2 000	4 000	12 000	24 000
Robots Assisté (Attended) Flottant Non assisté (Unattended)	4 000 1,600 1,600 800	8 000 3,200 3,200 1,600	24 000 9 600 9 600 4 800	48 000 19 200 19 200 9 600
Paquets	8 000	16 000	48 000	96 000
Processus (Processes)	4 000	8 000	24 000	48 000
Files d'attente (Queues)	200	420	1 200	2 400
Éléments de file d'attente	1 120 000	1 500 000	3 000 000	5 000 000
Actifs	40 000	80 000	240 000	480 000
Planifications (Schedules)	400	800	2 400	4 800

Données dynamiques

Les données dynamiques font référence aux données ajoutées ou modifiées dans Orchestrator lors de l'exécution des processus.

Entité	Un seul nœud	Deux nœuds	Cinq nœuds	Dix nœuds
Élément de la file d'attente (Queue Items) (par jour)	112 000	175,000	672 000	1 250 000
Exécutions (Jobs) (par minute)	2 000	4 000	12 000	24 000
Journaux (Logs) (par minute)	20,000	20,000	20,000	25,000
Téléchargements Nuget (Nuget Downloads) (maximum par minute)	2 000	4 000	12 000	24 000
Robots connectés (Robots Connected) (Maximum)	4 000	8 000	24 000	48 000
Pulsation (Heartbeat) (par minute)	10,000	20,000	60,000	120,000
Notifications SignalR (SignalR Notifications) (par minute)	2 000	4 000	12 000	24 000
Robots occupés	2 000	4 000	12 000	24 000
Robots disponibles	2 000	4 000	12 000	24 000