- 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)
- Meilleures pratiques
- Installation
- Mise à jour en cours
- Serveur d'identité
- Module complémentaire haute disponibilité
- Résolution des erreurs de démarrage
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.
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 licences High Availability Add-on.
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.
