- Démarrage
- Prérequis
- Prérequis matériels
- Prérequis logiciels
- Meilleures pratiques
- Installation
- Mise à jour en cours
- Serveur d'identité
- Résolution des erreurs de démarrage
Prérequis matériels
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). En fonction de l'option de déploiement de votre choix et de la taille de l'environnement que vous prévoyez de créer, vous devez consulter les différentes configurations matérielles requises.
Ce chapitre donne un aperçu des configurations matérielles requises spécifiques à certains de ces scénarios.
La configuration matérielle requise diffère entre votre environnement de développement et l'environnement de production. Bien que la même configuration matérielle requise que votre environnement de production puisse être utilisée à des fins de test et de développement, cela implique des coûts plus élevés et inutiles, en particulier dans les déploiements à grande échelle.
Cette configuration requise suppose un maximum de 100 robots Unattended s'exécutant simultanément. Deux machines peuvent être utilisées, l'une pour Orchestrator et (facultativement) Elasticsearch, et l'une pour SQL Server, configurées comme suit :
Serveur d'applications Web
|
Cœurs du processeur (>2 GHz) |
RAM (Go) |
Disque dur (Go) |
|---|---|---|
|
4 |
4 |
150 |
SQL Server
|
Cœurs du processeur (>2 GHz) |
RAM (Go) |
Disque dur (Go) |
|---|---|---|
|
4 |
8 |
300 |
Pour les environnements de production, il est fortement recommandé de fournir un serveur dédié pour chaque rôle :
- Application Web Orchestrator.
- Moteur de base de données SQL Server.
- Elasticsearch et Kibana.
Pour une installation à nœuds multiples, outre les conditions ci-dessus, les suivantes sont également requises :
- pour Orchestrator (au moins 3 nœuds HAA sont requis pour une réelle haute disponibilité et au moins 6 nœuds HAA pour la géo-redondance.
Remarque :
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 dépendant de ce protocole.
Le module HAA est la seule solution de ce type prise en charge par UiPath.
La configuration matérielle de chaque serveur requis dépend de la taille de votre déploiement, comme détaillé ci-dessous. La configuration matérielle requise présentée ici a été effectuée selon les tests dans lesquels un robot a été défini comme suit :
- des messages sont envoyés du Robot vers Orchestrator avec une fréquence de 1 message par seconde
- en moins de 60 secondes, le Robot envoie :
- 15 journaux de messages
- 2 pulsations
- 6 requêtes d'obtention d'actifs
- 6 requêtes d'ajout d'éléments de file d'attente
- 6 requêtes d'obtention d'éléments de file d'attente
Prise en charge de près de 250 Robots non assistés
Serveur d'applications Web
|
Nombre de Robots (Number of Robots) |
Cœurs de processeur (min 2 GHz) |
RAM (Go) |
Disque dur (Go) |
|---|---|---|---|
|
<20 |
4 |
4 |
100 |
|
<50 |
4 |
4 |
100 |
|
<100 |
4 |
4 |
150 |
|
<200 |
4 |
4 |
200 |
|
<250 |
4 |
4 |
200 |
UiPath.Orchestrator.dll.config. Pour ce faire, ajoutez le paramètre Max Pool Size=500 à la chaîne de connexion, de sorte qu’il ressemble à cet exemple :
<add name="Default" providerName="System.Data.SqlClient" connectionString="Server=SQL4142;Integrated Security=True;Database=UiPath;Max
Pool Size=500;" />
SQL Server
|
Nombre de Robots (Number of Robots) |
Cœurs de processeur (min 2 GHz) |
RAM (Go) |
Disque dur (Go) |
|---|---|---|---|
|
<20 |
4 |
8 |
100 |
|
<50 |
4 |
8 |
200 |
|
<100 |
4 |
8 |
300 |
|
<200 |
8 |
8 |
SSD 400 |
|
<250 |
8 |
16 |
SSD 400 |
Les prérequis de l'espace disque dépendent fortement des points suivants :
- Si les files d'attente de travail sont utilisées ou non : dans le premier cas, cela dépend du nombre moyen de transactions ajoutées tous les jours/toutes les semaines et de la taille (nombre de champs, taille de chaque champ) de chaque transaction.
- De la période de rétention des éléments de la file d'attente correctement traités (le client doit implémenter sa propre politique de rétention).
- Si les messages consignés par les Robots sont enregistrés ou non dans la base de données. Dans le premier cas, un filtre peut être appliqué pour enregistrer uniquement dans la BD des niveaux spécifiques de messages (par exemple, enregistrez dans la BD les messages avec le niveau de journalisation Erreur (Error) et Critique(Critical), et enregistrez dans Elasticsearch les messages avec le niveau de journalisation Info, Avertissement(Warn) et Traçage (Trace)).
- Des fréquences des messages de journalisation : le développeur de type Robot utilise à volonté l'activité Message du journal des événements (Log Message), chaque fois qu'il estime qu'un message vaut la peine d'être consigné.
- De la période de rétention des anciens messages consignés (le client doit implémenter sa propre politique de rétention).
- De la valeur du niveau de journalisation configurée dans le robot. Par exemple, si le niveau de journalisation dans le Robot est configuré sur Info, seuls les messages avec les niveaux Info, Avertissement (Warn), Erreur (Error) et Critique(Critical) sont envoyés à Orchestrator. les messages avec les niveaux Débogage (Debug), Traçage (Trace) et Détaillé(Verbose) sont ignorés et ils ne seront pas transmis à Orchestrator.
Serveur Elasticsearch
|
Nombre de Robots (Number of Robots) |
Cœurs de processeur (min 2 GHz) |
RAM (Go) |
Disque dur (Go) |
|---|---|---|---|
|
<20 |
4 |
4 |
100 |
|
<50 |
4 |
4 |
100 |
|
<100 |
4 |
8 |
150 |
|
<200 |
4 |
12 |
200 |
|
<250 |
4 |
12 |
300 |
Les prérequis de l'espace disque dépendent des points suivants :
- De la période de rétention (le client doit implémenter sa propre stratégie de rétention).
- Des fréquences des messages de journalisation : le développeur de type Robot utilise à volonté l'activité Message du journal des événements (Log Message), chaque fois qu'il estime qu'un message vaut la peine d'être consigné.
- De la valeur du niveau de journalisation configurée dans le robot. Par exemple, si le niveau de journalisation dans le Robot est configuré sur Info, seuls les messages avec les niveaux Info, Avertissement(Warn), “Erreur” (Error) et “Critique” (Critical) sont envoyés à Orchestrator. Les messages avec les niveaux “Débogage” (Debug) “Traçage” (Trace) et “Détaillé” (Verbose) sont ignorés et ils ne seront pas transmis à Orchestrator.
Remarque : pour plus de 50 robots, vous devez indiquer à la machine virtuelle Java utilisée par Elasticsearch d'utiliser 50 % de la RAM disponible, en définissant les arguments
-Xmset-Xmxsur la moitié de la quantité totale de mémoire. Cela se fait via la variable d'environnementES_JAVA_OPTSou en modifiant le fichierjvm.options.
Prise en charge de 250 à 500 robots non assistés
Serveur d'applications Web
|
Nombre de Robots (Number of Robots) |
Cœurs de processeur (min 2 GHz) |
RAM (Go) |
Disque dur (Go) |
|---|---|---|---|
|
<300 |
8 |
8 |
200 |
|
<400 |
8 |
8 |
220 |
|
<500 |
16 |
16 |
250 |
SQL Server
|
Nombre de Robots (Number of Robots) |
Cœurs de processeur (min 2 GHz) |
RAM (Go) |
Disque dur (Go) |
|---|---|---|---|
|
<300 |
16 |
32 |
SSD 400 |
|
<400 |
16 |
32 |
SSD 500 |
|
<500 |
16 |
32 |
SSD 600 |
Pour plus de 300 Robots, pensez à ne pas enregistrer tous les messages consignés dans la base de données SQL Server. Enregistrez dans la BD uniquement les messages avec le niveau de journalisation Erreur (Error) et Critique(Critical). Enregistrez tous les messages (à savoir Erreur(Error) et Critique(Critical) ) dans Elasticsearch.
Serveur Elasticsearch
|
Nombre de Robots (Number of Robots) |
Cœurs de processeur (min 2 GHz) |
RAM (Go) |
Disque dur (Go) |
|---|---|---|---|
|
<300 |
4 |
12 |
300 |
|
<400 |
4 |
16 |
500 |
|
<500 |
4 |
16 |
600 |
La section suivante donne un exemple de déploiement important et évolutif utilisant les offres Azure Infrastructure as a Service (IaaS). Cette configuration a été utilisée :
- Ensemble de disponibilité de machine virtuelle pour Orchestrator
- Groupe de machines virtuelles à haute disponibilité pour Elasticsearch
- Windows Server SQL VM
- Azure Load Balancer
- Service DNS distribué (tel que Cloudflare)
Architecture
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) |
Disque (Disk) |
|---|---|---|---|
|
1-2 |
8 |
16 |
1 To - disque ultra SSD pour base de données, tempDB et journal transactionnel |
|
5 |
16 |
32 |
1 To - disque ultra SSD pour base de données 1 To - disque ultra SSD pour tempDB 1 To - disque ultra SSD pour journal transactionnel |
|
10 |
32 |
64 |
1 To - disque ultra SSD pour base de données 1 To - disque ultra SSD pour tempDB 1 To - disque ultra SSD pour journal transactionnel |
|
15 |
40 |
96 |
1 To - disque ultra SSD pour base de données 1 To - disque ultra SSD pour tempDB 1 To - disque ultra SSD pour journal transactionnel |
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
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.
É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.
Module complémentaire haute disponibilité
-
pour Orchestrator (au moins 3 nœuds HAA sont requis pour une réelle haute disponibilité et au moins 6 nœuds HAA pour la géo-redondance.
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.
Les déploiements haute disponibilité d'Orchestrator sont pris en charge par UiPath uniquement si le module complémentaire haute disponibilité UiPath est utilisé.
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'à 6 000 |
|
2 |
jusqu'à 14 000 |
|
5 |
jusqu'à 8 000 |
|
10 |
jusqu'à 24 000 |
|
15 |
jusqu'à 300 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
Les données affichées dans les 2 tableaux suivants sont représentatives d’un déploiement Attended.
Données statiques
Les données statiques font référence à la charge initiale d'Orchestrator.
|
Entité |
Un seul nœud |
Deux nœuds |
Cinq nœuds |
Dix nœuds |
Quinze nœuds |
|---|---|---|---|---|---|
|
Tenants |
1 |
1 |
1 |
1 |
1 |
|
Dossiers |
1 |
2 |
4 |
4 |
6 |
|
Robots |
6 000 |
14 000 |
80 000 |
200 000 |
300 000 |
|
Paquets |
8 000 |
16 000 |
48 000 |
48 000 |
48 000 |
|
Processus (Processes) |
4 000 |
8 000 |
24 000 |
24 000 |
24 000 |
|
Files d'attente (Queues) |
600 |
1 200 |
1 800 |
2 400 |
3 000 |
|
Éléments de file d'attente |
1 120 000 |
1 500 000 |
3 000 000 |
5 000 000 |
7 000 000 |
|
Actifs |
500 |
1 000 |
1 500 |
3 000 |
4 500 |
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 |
Quinze nœuds |
|---|---|---|---|---|---|
|
Élément de la file d'attente (Queue Items) (par jour) |
300 000 |
600 000 |
4 000 000 |
9 000 000 |
10 500 000 |
|
Exécutions (Jobs) (par minute) |
700 |
1 500 |
3 000 |
6 000 |
7 500 |
|
Journaux (Logs) (par minute) |
20,000 |
50 000 |
300 000 |
600 000 |
800 000 |
|
Téléchargements Nuget (Nuget Downloads) (maximum par minute) |
1 000 |
3 000 |
10,000 |
14 000 |
18 000 |
|
Robots connectés (Robots Connected) (Maximum) |
6 000 |
14 000 |
80 000 |
200 000 |
300 000 |
|
Pulsation (Heartbeat) (par minute) |
12 000 |
28 000 |
160 000 |
400 000 |
600 000 |
|
Robots occupés |
3 000 |
7 000 |
40 000 |
100 000 |
150 000 |
|
Robots disponibles |
3 000 |
7 000 |
40 000 |
100 000 |
150 000 |
Les sections suivantes offrent un aperçu des capacités d’un déploiement PaaS en termes de performances.
Architecture
Les prérequis suivants sont nécessaires :
-
Orchestrator :
- Orchestrator App Service Plan : 20 instances P3V2
- Azure SQL Server : Premium P15 : 4000 DTU
- Azure Redis cache P2 Premium 13 Go
-
Identity Server :
- Identity Server App Service Plan : 2 instances P3V2
- Serveur SQL Azure : Standard S7 : 800 DTU
-
Elasticsearch :
Tests de performances
Les données affichées dans les tableaux suivants sont représentatives d’un déploiement Attended.
Données statiques
Les données statiques font référence à la charge initiale d'Orchestrator.
|
Entité |
Un seul nœud |
|---|---|
|
Tenants |
1 |
|
Dossiers |
8 000 |
|
Robots |
80 000 |
|
Paquets |
8 000 |
|
Processus (Processes) |
8 000 |
|
Files d'attente (Queues) |
8 000 |
|
Éléments de file d'attente |
2 000 000 |
|
Actifs |
8 000 |
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 |
|---|---|
|
Élément de la file d'attente (Queue Items) (par jour) |
5 000 000 |
|
Exécutions (Jobs) (par minute) |
2 600 |
|
Journaux (Logs) (par minute) |
240 000 |
|
Téléchargements Nuget (Nuget Downloads) (maximum par minute) |
2 000 |
|
Robots connectés (Robots Connected) (Maximum) |
80 000 |
|
Pulsation (Heartbeat) (par minute) |
160 000 |
|
Robots occupés |
40 000 |
|
Robots disponibles |
40 000 |
|
Port |
Description |
|---|---|
|
443 | Port par défaut pour la communication entre les utilisateurs et Orchestrator avec les Robots connectés. |
|
1433 | Port par défaut pour la communication entre Orchestrator et la machine exécutant SQL Server. |
|
9200 | Communication entre Orchestrator et Elasticsearch. |
|
9300 | Communication entre les nœuds Elasticsearch, le cas échéant. |
|
5601 | Port par défaut utilisé par le plugin Kibana, le cas échéant. |
|
3389 | Requis pour l'automatisation RDP, nécessaire pour les robots haute densité. |
