Ce document est une réponse à une demande impliquant les versions d’ePO et la prise en charge de la fonctionnalité SQL
AlwaysOn . McAfee analyse entreprise du problème a conclu que cette fonctionnalité fonctionne sans problème tant qu’elle est configurée correctement.
Description du problème
- La fonctionnalité groupes de disponibilité AlwaysOn est une solution haute disponibilité et reprise sur sinistre qui offre une alternative à l’entreprise à la mise en miroir de bases de données.
- Introduite dans SQL Server 2012, les groupes de disponibilité AlwaysOn optimisent la disponibilité d’un ensemble de bases de données utilisateur pour une entreprise.
- Un groupe de disponibilité prend en charge un environnement de basculement pour un ensemble discret de bases de données utilisateur, connues sous le nom de bases de données de disponibilité, qui basculent ensemble.
- Un groupe de disponibilité prend en charge les deux éléments suivants :
- Ensemble de bases de données principales de lecture ou d’écriture
- Un à huit ensembles de bases de données secondaires correspondantes
Recherches et conclusions
- ePO fonctionne avec la fonction AlwaysOn SQL.
- Il n’y a pas de différence si la base de données est en cours d’exécution sur un AlwaysOn Failover Cluster Instance , ou Windows Server Failover Cluster. Pour plus d’informations, voir KB74034-prise en charge d’ePolicy Orchestrator et de la mise en miroir SQL.
- La AlwaysOn fonction fait partie de SQL, et non d’EPO, et tout problème se présenterait dans la configuration correcte de la AlwaysOn fonction.
- Mais il existe une limitation à ce qu’ePO prenne en charge les nœuds de cluster de basculement sur le même sous-réseau.
- Une configuration de cluster de basculement à plusieurs sous-réseaux ne fonctionne pas avec ePO.
- Il existe deux manières de configurer un SQL Server cluster de basculement, comme décrit dans l’article Microsoft ci-dessous. Pour plus d’informations, reportez-vous à l' article Microsoft:
Selon la façon dont les nœuds sont organisés en clusters, le cluster de basculement SQL Server est configuré de l’une des manières suivantes :
- Nœuds sur un sous-réseau différent
La dépendance de ressource d’adresse IP est définie sur ou. Cette configuration est appelée configuration d’un cluster de basculement à plusieurs sous-réseaux SQL Server. Pour plus d’informations, reportez-vous à la section SQL Server multi-sous-réseau en cluster (SQL Server).
- Nœuds sur le même sous-réseau ou le même ensemble de sous-réseaux
La dépendance de ressource d’adresse IP est définie sur et pour ces types de configurations.
Important : La première option ci-dessus n’est pas prise en charge et ne fonctionne pas avec ePO. Toutefois, ePO prend en charge la deuxième option.
REMARQUES :
- Les tâches serveur en cours au cours du basculement ne peuvent pas se terminer correctement après le basculement.
- Ces tâches doivent être interrompues à l’aide de l’option "fin de tâche" du journal des tâches serveur de la console ePO. Cette action est nécessaire car ePO n’a pas connaissance de l’opération de reprise de la base de données.
- Lors du basculement, les connexions de base de données ouvertes associées à une tâche serveur ePO et au nœud principal (Primary) que le SQL Server supprime. Ainsi, les tâches serveur restent dans l’État « en cours » ou « en attente » jusqu’à ce que la tâche soit fermée via la console ePO.
Remarque : Toute autre fonctionnalité ou toute autre version de produit mentionnée dans la base de connaissances est conçue pour présenter la direction générale du produit et ne doit pas être considérée comme un engagement ou pour prendre une décision d’achat.