orchestrator
2022.4
false
Important :
Veuillez noter que ce contenu a été localisé en partie à l’aide de la traduction automatique. La localisation du contenu nouvellement publié peut prendre 1 à 2 semaines avant d’être disponible.
UiPath logo, featuring letters U and I in white

Guide d'installation d'Orchestrator

Automation CloudAutomation Cloud Public SectorAutomation SuiteStandalone
Dernière mise à jour 7 oct. 2024

Récupération d'urgence (Disaster Recovery) - Deux centres de données actifs (Two Active Data Centers)

Le modèle de déploiement illustré ci-dessous peut être implémenté pour garantir à la fois la haute disponibilité et la récupération d'urgence. Ici, les deux nœuds d'Orchestrator sont actifs et l'équilibreur de charge dirige le trafic vers eux à l'aide d'un algorithme spécifique, tel que Round Robin ou l'une de ses variantes.

Cette configuration nécessite une bonne connectivité réseau entre les centres de données, situés dans différentes zones géographiques. Le modèle peut être implémenté sur site ou dans le cloud. Pour le déploiement dans le cloud, vous devez choisir des régions différentes pour les emplacements principal et secondaire.

Remarque :

Ce modèle de déploiement nécessite les éléments suivants :

  • SQL Server 2012 ou version ultérieure et le module complémentaire High Availability pour Orchestrator. Les versions antérieures de SQL Server ne prennent pas en charge AG, et une configuration Actif-Actif n'est pas prise en charge par Redis open source.
  • Deux .


Pour fournir une haute disponibilité à l'équilibreur de charge réseau (si le NLB se situe dans le centre de données principal), un NLB secondaire doit être fourni dans le centre de données à récupération d'urgence. Les deux NLB doivent être placés dans une configuration Principal-Secondaire (ou Maître-Esclave).

Dans le même centre de données, vous pouvez utiliser un NLB, avec différents serveurs virtuels (VIP) pour Ochestrator et Elasticsearch. Ce même NLB peut être utilisé pour répartir de manière optimale les charges sur les nœuds Orchestrator et Elasticsearch.

La fonctionnalité Groupe de disponibilité Always On peut être composée d'au moins 2 machines :

  • BD principale dans le premier centre de données ;
  • BD secondaire dans le second centre de données.

    Remarque : Trois nœuds minimum sont requis pour HAA et Elasticsearch dans chaque centre de données, configurés dans des clusters différents et synchronisés.

Consultez ici les prérequis, les restrictions et les recommandations pour Groupe de disponibilité Always On.

Cette page vous a-t-elle été utile ?

Obtenez l'aide dont vous avez besoin
Formation RPA - Cours d'automatisation
Forum de la communauté UiPath
Uipath Logo White
Confiance et sécurité
© 2005-2024 UiPath Tous droits réservés.