Discussion :

[aolelien]

Bonjour à tous,

Nous souhaitons monter une architecture proche de celle ci-dessous :



Configuration : groupes de disponibilités monté sur WSFC 5 noeuds

Les besoins sont :
- Failover automatique
- 1 serveur de reporting, replica secondaire asynchrone en lecture des groupes de disponibilités AVG1 et AVG2 (les bases Db1 et Db3 sont accessibles en lecture)


La problématique est la suivante :
Comment faire pour qu'en cas de défaillance d'une des bases (Db1 ou Db2) sur une instance SQL, les 2 groupes de disponibilités AVG_Db1 et AVG_Db2 basculent automatiquement vers le réplica secondaire (SecondaryServer1).
Car avec le modèle actuel, lors de la défaillance d'une des bases, le groupe de disponibilité contenant cette base va basculer automatiquement, mais la seconde base sera inaccessible (notre application a besoin des 2 bases pour fonctionner).

contraintes :
- Nous ne voulons pas payer une licence supplémentaire pour les serveurs secondaires (donc bases non accessibles en lecture), ni avoir les bases Db2 et Db4 sur le serveur de reporting.
- Pas de mutualisation des bases (Db1 avec Db2 et Db3 avec Db4).

Des idées ou est-ce tout simplement impossible?
Merci d'avance.

[mikedavem]

Hello,

Avec les listeners pas vraiment de souci puisque les 2 bases restent accessibles par l'application si elles passent par les listeners.
Est-ce que tu sous entends que des transactions cross db s'effectuent? Si c'est le cas je vois 2 solutions possibles:

- La solution "bricolo" à base de script qui fait basculer l'ensemble des groupes quand un bascule.
- La solution plus propre est de changer le design actuel en ne faisant qu'un seul groupe de disponibilité et en utilisant du log-shipping par exemple en complément pour la partie reporting. Le log-shipping apporte son lot de désavantage bien entendu: pas de reporting "real time" et en fonction du mode tu peux avoir soit un certain retard sur le refresh de tes data ou une déconnexion sauvage de tes utilisateurs. Mais si c'est acceptable pour l'un ou pour l'autre alors cela reste une solution possible.


++

[SQLpro]

Bonjour à tous,

Nous souhaitons monter une architecture proche de celle ci-dessous :



Configuration : groupes de disponibilités monté sur WSFC 5 noeuds

Première question : êtes vous en édition Enterprise ou standard ?

Les besoins sont :
- Failover automatique
- 1 serveur de reporting, replica secondaire asynchrone en lecture des groupes de disponibilités AVG1 et AVG2 (les bases Db1 et Db3 sont accessibles en lecture)


La problématique est la suivante :
Comment faire pour qu'en cas de défaillance d'une des bases (Db1 ou Db2) sur une instance SQL, les 2 groupes de disponibilités AVG_Db1 et AVG_Db2 basculent automatiquement vers le réplica secondaire (SecondaryServer1).
Car avec le modèle actuel, lors de la défaillance d'une des bases, le groupe de disponibilité contenant cette base va basculer automatiquement, mais la seconde base sera inaccessible (notre application a besoin des 2 bases pour fonctionner).

Si tel est le cas : "notre application a besoin des 2 bases pour fonctionner", vous avez une erreur de design. Il aurait fallu plutôt jouer sur les schéma SQL au sein d'une même base. Ré étudiez cette architecture, car, au delà de la haute dispo, vous aurez de multiples problèmes tel que la remontée consistante de vos sauvegardes qui ne peuvent en aucun cas être synchronisées….

A +

[mikedavem]

Première question : êtes vous en édition Enterprise ou standard ?

Je pense qu'il est en enterprise sinon il n'aura jamais pu mettre un 3ème noeud dans son architecture (du moins c'est ce que j'ai supposé ...)

++

[aolelien]

Hello,

Avec les listeners pas vraiment de souci puisque les 2 bases restent accessibles par l'application si elles passent par les listeners.
Est-ce que tu sous entends que des transactions cross db s'effectuent? Si c'est le cas je vois 2 solutions possibles:

- La solution "bricolo" à base de script qui fait basculer l'ensemble des groupes quand un bascule.
- La solution plus propre est de changer le design actuel en ne faisant qu'un seul groupe de disponibilité et en utilisant du log-shipping par exemple en complément pour la partie reporting. Le log-shipping apporte son lot de désavantage bien entendu: pas de reporting "real time" et en fonction du mode tu peux avoir soit un certain retard sur le refresh de tes data ou une déconnexion sauvage de tes utilisateurs. Mais si c'est acceptable pour l'un ou pour l'autre alors cela reste une solution possible.


++

Merci pour votre retour,
- Il y'aura effectivement des transactions crossDb d'où la nécessité d'avoir les 2 bases accessible en Read sur la même instance
- Comme vous le dites, le problème du logshipping c'est le fait que la base ne soit pas accessible en lecture à tout moment, ce qui est un des besoins (mea culpa, je ne l'ai pas précisé).

[aolelien]

Première question : êtes vous en édition Enterprise ou standard ?Si tel est le cas : "notre application a besoin des 2 bases pour fonctionner", vous avez une erreur de design. Il aurait fallu plutôt jouer sur les schéma SQL au sein d'une même base. Ré étudiez cette architecture, car, au delà de la haute dispo, vous aurez de multiples problèmes tel que la remontée consistante de vos sauvegardes qui ne peuvent en aucun cas être synchronisées….

A +

Bonjour,

Oui la version est bien Enterprise.
Les bases Db2 et Db4 ne seront accédées qu'en lecture et seront alimentées via de la réplication transactionnelle.
La principale raison pour laquelle nous les avons séparées des bases Db1 et Db3 (bases principales) c'était pour avoir la possibilité d'utiliser dans le futur, des réplicas Asynchrone avec répartition de charge (pour les requêtes ne contenant pas de transactions CrossDb), si le besoin s'en faisait ressentir.
Mais il semblerait que le plus "propre" et optimisé serait de revenir, comme vous le dites, à une seule base.

Merci pour vos réponses.

[mikedavem]

S'il est possible de toucher au schéma encore mieux ...

++