Discussion :

[Ornitho76]

Bonjour à tous,

Dans le cadre d'une nouvelle infrastructure pour notre ERP (pour information Dynamics AX), nous voulons implémenter de la haute disponibilité avec SQL Server 2014. La principale contrainte étant qu'à l'heure actuelle, nous avons plusieurs sites distants, tous se connectant sur un même site "principal" où se trouve l'ERP en question.

La première étude nous a amener à mettre en place un groupe de Haute disponibilité Always On. Pas de soucis, cela est devenu quelque chose de classique maintenant pour un environnement de production. Tous les sites continuerons à se connecter au site "principal" pour utiliser l'ERP.

Puis on nous a demandé, pour des raisons de sécurité, d'avoir au moins 1 nœud sur chaque site distant, donc la deuxième solution a été d'ajouter autant de nœud dans notre groupe de haute disponibilité que de site distant, jusqu'à la limite autorisé par SQL Server 2014. Les sites se connectant toujours au site "principal" pour utiliser l'ERP, une latence existera si le nœud principal du groupe de haute disponibilité n'est pas sur le site où se trouve l'ERP.

Et c'est là que se pose notre problématique.

Partant du principe où nous avons un nœud sur chaque site et que tous les sites se connectent au site "principal" pour utiliser l'ERP, en cas de coupure d'un lien réseau entre site, et qu'un site se retrouve isolé, il sera dans l'impossibilité de se connecter à l'ERP du site "principal".
Nous avons réfléchi à mettre en place des ERP de secours ou secondaire sur chaque site pour ce cas là et d'utiliser le nœud se trouvant sur ce site. Mais cela pose plusieurs problèmes voir même impossible à ma connaissance.

Le premier soucis est qu'un noeud se trouvant dans un groupe de haute disponibilité ne peut pas être interrogé directement s'il est secondaire (lecture ET écriture) et donc s'il se retrouve isolé du groupe de haute disponibilité en cas de coupure, que faire ? Faut-il le sortir du groupe de haute disponibilité pour pouvoir le connecter directement à l'ERP du site ? Est-ce que cela est possible sachant que le groupe de haute disponibilité n'est pas joignable ? Et si tenté que cela soit possible, comment gérer le moment où le lien revient, des transactions auront été traités sur le serveur isolé ainsi que dans le groupe de haute disponibilité donc impossible de reformer le groupe de haute disponibilité de départ.

Cette problématique me paraît compliqué mais il existe peut-être des solutions dont j'ignore l'existence, soit par le biais de mécanisme propre à SQL Server ou bien par des logiciels tiers ou encore via une architecture plus complète pouvant gérer cette problématique.

[SQLpro]

...
Le premier soucis est qu'un noeud se trouvant dans un groupe de haute disponibilité ne peut pas être interrogé directement s'il est secondaire (lecture ET écriture) et donc s'il se retrouve isolé du groupe de haute disponibilité en cas de coupure, que faire ?

Cette question est purement fonctionnelle et doit être posée en interne...

Faut-il le sortir du groupe de haute disponibilité pour pouvoir le connecter directement à l'ERP du site ?

Dans ce cas cela devient une base autonome et il n'y a aucune possibilité de récupérer les nouvelles données pour consolider une autre base.

Est-ce que cela est possible sachant que le groupe de haute disponibilité n'est pas joignable ?

Oui, avec les conséquence que je viens d'évoquer => suppression du groupe de disponibilité AlwaysOn

Et si tenté que cela soit possible, comment gérer le moment où le lien revient, des transactions auront été traités sur le serveur isolé ainsi que dans le groupe de haute disponibilité donc impossible de reformer le groupe de haute disponibilité de départ.

Il faudra vous démerder manuellement ! Autrement dit impossible à faire...

Cette problématique me paraît compliqué mais il existe peut-être des solutions dont j'ignore l'existence, soit par le biais de mécanisme propre à SQL Server ou bien par des logiciels tiers ou encore via une architecture plus complète pouvant gérer cette problématique.

En fait on vous a mené sur une fausse piste.
Le but de AlwaysOn est d'assurer une disponibilité de LA BASE (ou du groupe de bases) et non de plusieurs clones de la même bases (ou plusieurs clones du groupes de base). Dès que deux bases réplica vont être accessible en écriture il n'existe aucun moyen, de report des données de l'un vers l'autre et réciproquement. Il faudra choisir quelle base survit et laquelle est à abandonner et comparer manuellement es données à reporter de l'une vers l'autre !!!
Autrement dit l'architecture que 'on vous a demandé de mettre en œuvre est totalement foireuse et conduit à une impasse !

Bref, il aurait fallut faire une étude préalable !

A +

[Ornitho76]

Merci pour ce retour.

L'architecture n'est pas encore en place, car j'ai effectivement indiqué que cela n'était pas possible avec les connaissances que j'avais sur AlwaysOn.
Il s'agit d'une nouvelle étude sur cette hypothétique architecture et pour laquelle nous n'avons pas de réponse en interne. Et visiblement pas de réponse court car architecture impossible avec AlwaysOn.

Et en écartant AlwaysOn, existe-t-il une technologie ou un mécanisme se rapprochant de ce que "l'on" voudrait mettre en place ?

[SQLpro]

Et en écartant AlwaysOn, existe-t-il une technologie ou un mécanisme se rapprochant de ce que "l'on" voudrait mettre en place ?

Cela existe de manière automatique dans certaines systèmes de gestion de bases de données. Mais c'est plus qu'anecdotique car cela renvoit systématiquement au paradoxe temporel... Or il conduit toujours a des impossibilités de récupération de l'état complet. Il faut donc faire des choix de perte.
Un exemple :
soit une table avec auto incrément qui en est resté à 100.
La base principale A tombe en panne et 2 bases B et C deviennent actives...
Dans la base B on insère un nouveau client qui prends le n° 100, puis des commandes, des factures...
En parallèle dans la base C on insère aussi un nouveau client qui prends le n° 100, puis des commandes, des factures...
Comment remettre le tout dans une même base ? Et ci ces deux clients n'était qu'un seul et même client ? Que faire de deux clients identiques ayant l'identifiant 123 dans la base B et 456 dans la base C avec des factures pour chacun ???

Il n'existe aucun moyen sur et efficace pour recoller les morceaux. Vous êtes dans une dualité !

A +

[Ornitho76]

Je comprends les problèmes que cela pose effectivement.

Il me vient une autre question qui est plus liée à la configuration de AlwaysOn en multisite.
Prenons l'exemple suivant :

Sur chaque site se trouve un SQL Server et ces serveurs se trouve dans un cluster pour pouvoir former un groupe de haute disponibilité.
Si un des sites perd la connexion avec les autres, comment se porte le cluster si sur ce site se trouve le stockage partagé pour le quorum ? (J'espère ne pas me tromper dans mon explication)
Quel serait la bonne architecture pour que le groupe de haute disponibilité puisse continuer de fonctionner pour les autres sites ?

[SQLpro]

Si l'un des sites perd la connexion alors l'ensemble des groupes restent en l'état. Le principal actif reste actif et exploitable. Les réplicas passif connectés reçoivent les données et les intègrent. Le replica passif déconnecté attend sagement que la connections soit rétablie pour faire un rattrapage de synchronisation... Ceci peut avoir comme conséquence :
1) d'augmenter la taille du journal de transaction des bases actives (les transactions non encore envoyés sont "retenues")
2) de générer une phase de resynchronisation plus ou moins longue sur le réplicas déconnecté dès qu'il se reconnectera, longueur fonction du temps pendant lequel il a perdu la connexion.
Si c'est le réplica actif qui a perdu la connexion, les passifs ne sont plus alimentés. Si vos applications ne peuvent plus accéder au serveur (car la connexion est perdue) alors vous devez prendre une décision :
soit attendre un rétablissement du système, soit forcer un basculement sur l'un des réplica.
C'est pourquoi pour palier à ce cas de figure qui est un spof si vous n'avez qu'une seule carte réseau et qu'un seul réseau, il est de bon ton d'avoir plusieurs cartes réseau physiques différentes sur le serveur et un routage différent pour chacune des cartes afin que le réseau lui même soit résilient (switches différents...).

Quel serait la bonne architecture pour que le groupe de haute disponibilité puisse continuer de fonctionner pour les autres sites ?

La haute disponibilité via ALwaysOn assure une couverture en cas de panne des serveurs et/ou base de manière automatique, mais pas en cas de panne de l'infrastructure elle même pour la bonne et simple raison que si c'est votre infra, d'autres systèmes ont toutes les chances d'être eux aussi victime de la panne (serveurs web, routeurs, switches...).

A +