- Démarrage
- Prérequis
- Prérequis matériels
- Prérequis logiciels
- Serveur Web sur une seule machine (Web Server on a Single Machine)
- Déploiement multinœud
- Haute disponibilité (High Availability)
- Récupération d'urgence (Disaster Recovery) - Active/Passive
- Récupération d'urgence (Disaster Recovery) - Deux centres de données actifs (Two Active Data Centers)
- Déploiement dans le cloud (Deployment in the Cloud)
- Meilleures pratiques
- Installation
- Mise à jour en cours
- Serveur d'identité
- High Availability Add-on
Déploiements de petite à moyenne envergure
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.
Environnements de développement
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 |
Environnements de production
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.
For a Multi-Node Installation, in addition to the above, the following is also required:
-
High Availability add-on (HAA) for Orchestrator (3+ HAA nodes are required for true high availability and 6+ HAA nodes for geo-redundancy.
Remarque :Multi-node Orchestrator deployments use the RESP (Redis Serialization Protocol) for communication, and thus can be configured using any solution relying on this protocol.
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 :
- 40 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 |
Pour plus de 200 robots, portez à 200 le nombre de connexions autorisées dans le pool de la chaîne de connexion SQL à partir du fichier UiPath.Orchestrator.dll.config. Pour ce faire, ajoutez le paramètre Max Pool Size=200 à 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=200;" />
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 demander à la Machine virtuelle Java utilisée par Elasticsearch d'utiliser 50 % de la RAM disponible, en configurant les arguments
-Xmset-Xmxsur la moitié de la quantité totale de mémoire. Pour ce faire, utilisez la variable d'environnementES_JAVA_OPTSou modifiez 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 | 8 | 250 |
Pour plus de 400 Robots, il est recommandé de passer le nombre de cœurs du processeur à 16.
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 SQL Server Édition Standard, 16 cœurs de processeur représentent le maximum utilisé par l'édition Standard. Pour une machine virtuelle, veillez à que ce nombre de cœurs soit obtenu par 4 sockets virtuels avec 4 cœurs chacun (et pas par 2 sockets avec 8 cœurs ou 8 sockets avec 2 cœurs). Pour l'édition Enterprise, la combinaison pour obtenir 16 nœud n'importe pas.
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 |
Prise en charge de plus de 500 robots non assistés
If Orchestrator needs to support more than 500 Robots running simultaneously, you need to provide 2 or more Orchestrator nodes and 1 or more HAA nodes in a farm, under a Network Load Balancer. Each node should have the hardware requirements according to the number of Robots it serves by request from the Load Balancer. But remember that the SQL Server is still one single machine (even with Always On Availability Groups, the Primary Replica is the one responsible to serve all the I/O requests). Therefore you need to:
- Passez la RAM de SQL Server à 64 Go.
- Enregistrez UNIQUEMENT les niveaux de journalisation Erreur(Error) et Critique(Critical) à partir du Robot dans la BD.
SQL Server
| Nombre de Robots (Number of Robots) | Cœurs de processeur (min 2 GHz) | RAM (Go) | Disque dur (Go) |
|---|---|---|---|
| 500 | 16 | 64 | SSD 800 |
Pour SQL Server Édition Standard, 16 cœurs de processeur représentent le maximum utilisé par l'édition Standard. Pour une machine virtuelle, veillez à que ce nombre de cœurs soit obtenu par 4 sockets virtuels avec 4 cœurs chacun (et pas par 2 sockets avec 8 cœurs ou 8 sockets avec 2 cœurs). Pour l'édition Enterprise, la combinaison pour obtenir 16 nœud n'importe pas.
Ports TCP
| 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é. |