Discussion :

[AltDev]

Salut la communauté !

J'ai un dilemme.
Voici ce qu'un client m'a demandé :

- 2 machines sous Windows Server 2012 R2
- SQL Server 2012 sur les deux machines
- Réplication équivalent Master-Master pour une bdd.
- Failover en cas de crash.

D'après ce que j'ai vu, l'équivalent Master-Master sur SQL Server est la topologie Peer-To-Peer. Ca, c'est bon, les deux bases de données répliquent l'une sur l'autre à l'heure actuel.

Pour le failover, j'ai vu 2 solutions :

- AlwaysOn Availability :
Le problème pour cette solution est qu'elle nécessite l'AD DS, et donc forcément, un Domain Controller. Hors, après moult tests infructueux, j'ai compris qu'un Domain Controller ne pouvait pas être un nœud de failover cluster ( https://support.microsoft.com/en-us/kb/2795523 ), hors, je n'ai que 2 serveurs (le client refusera l'achat d'une troisième machine), donc le Domain Controller doit forcément être l'un d'entre eux. Du coup, j'ai laissé tomber cette solution pour l'instant.

- Mirroring :
Cette solution pose de multiples problèmes. D'abord, elle est incompatible avec la topologie Peer-To-Peer (https://msdn.microsoft.com/en-us/library/ms151799.aspx) ce qui ne me poserait pas de problème si elle répliquait des données dans un équivalent Master-Master, mais cela ne semble pas être le cas (ou j'ai mal lu ?). Ensuite, il faut un serveur témoin pour activer l'option "failover automatique" soit activé, cependant, si je précise que le témoin est l'un des deux serveurs, si c'est celui-ci qui crash, le failover fonctionnera-t-il quand même ? Et enfin, il semble que le Mirroring soit voués à disparaitre dans les prochaines versions de SQL Server, ce qui n'est pas top pour le client.

Du coup, coincé, je viens vers vous en espérant que des experts me puisse me sauver

A noter que je suis moi-même plutôt débutant en SQL Server, voir en Windows Server, donc si vous venez de lire une énormité, toutes mes plus plates excuses !

[SQLpro]

Salut la communauté !

J'ai un dilemme.
Voici ce qu'un client m'a demandé :

- 2 machines sous Windows Server 2012 R2
- SQL Server 2012 sur les deux machines
- Réplication équivalent Master-Master pour une bdd.
- Failover en cas de crash.

Quel est votre besoin ? par ce que là vous allez direct au clash ! Est-ce de la haute disponibilité que vous cherchez ? Quel est le temps de latence ? Que est la fenêtre possible de perte de données ? Quel est la distance entre les nœuds ? Si vous n'avez que 2 machines, faire une réplication des données (qui n'a rien à voir avec une duplication de la base....) et en sus de la haute dispo est impossible ou stupide...

D'après ce que j'ai vu, l'équivalent Master-Master sur SQL Server est la topologie Peer-To-Peer. Ca, c'est bon, les deux bases de données répliquent l'une sur l'autre à l'heure actuel.

Non, vous n'avez pas compris ce qu'est la réplication des données et ce qu'est la haute dispo...

Pour le failover, j'ai vu 2 solutions :

- AlwaysOn Availability :
Le problème pour cette solution est qu'elle nécessite l'AD DS, et donc forcément, un Domain Controller. Hors, après moult tests infructueux, j'ai compris qu'un Domain Controller ne pouvait pas être un nœud de failover cluster ( https://support.microsoft.com/en-us/kb/2795523 ), hors, je n'ai que 2 serveurs (le client refusera l'achat d'une troisième machine), donc le Domain Controller doit forcément être l'un d'entre eux. Du coup, j'ai laissé tomber cette solution pour l'instant.

- Mirroring :
Cette solution pose de multiples problèmes. D'abord, elle est incompatible avec la topologie Peer-To-Peer (https://msdn.microsoft.com/en-us/library/ms151799.aspx) ce qui ne me poserait pas de problème si elle répliquait des données dans un équivalent Master-Master, mais cela ne semble pas être le cas (ou j'ai mal lu ?). Ensuite, il faut un serveur témoin pour activer l'option "failover automatique" soit activé, cependant, si je précise que le témoin est l'un des deux serveurs, si c'est celui-ci qui crash, le failover fonctionnera-t-il quand même ? Et enfin, il semble que le Mirroring soit voués à disparaitre dans les prochaines versions de SQL Server, ce qui n'est pas top pour le client.

Elle est obsolète depuis la version 2012

Du coup, coincé, je viens vers vous en espérant que des experts me puisse me sauver

A noter que je suis moi-même plutôt débutant en SQL Server, voir en Windows Server, donc si vous venez de lire une énormité, toutes mes plus plates excuses !

Oui, beaucoup de confusion...

Donnez-nous votre exigence fonctionnelle ! Que voulez vous faire ???

A +

[AltDev]

Salut !

Merci de ta réponse.

D'après ce que tu me dis, il semblerait que je comprenne mal beaucoup de chose. C'est probablement vrai, comme je l'ai déjà dit, SQL Server, la réplication, la HA et tout ce qui y est associé est tout sauf ma spécialité.

Quel est le temps de latence ? Que est la fenêtre possible de perte de données ? Quel est la distance entre les nœuds ? Si vous n'avez que 2 machines, faire une réplication des données (qui n'a rien à voir avec une duplication de la base....) et en sus de la haute dispo est impossible ou stupide...

Nous ne disposons pas de ces informations, le but étant simplement de créer un PIF d'une solution que le client pourra déployer lui-même.

Non, vous n'avez pas compris ce qu'est la réplication des données et ce qu'est la haute dispo...

Bon, dans ce cas, je vais essayer d'expliquer le but de la demande.
Le client souhaite avoir à disposition une machine contenant une base de donnée sur SQL Server. En cas de crash de cette machine, il souhaite qu'une autre machine prenne le relai, avec le même contenu, les mêmes données.
Donc, la solution trouvé par la team qui m'a confié ce travail était la réplication peer-to-peer entre les deux machines, et en effet, ça marche, les deux bases de données réplique la data aussitôt qu'elle est créé.
Ensuite, pour que l'autre machine prenne le relai en cas de crash, le failover. Pas grand chose à dire de plus que dans mon ancien post la dessus.

J'ai déjà pu créé cette solution juste avant sur CentOS/MariaDB, une réplication Master/Master + failover, rien d'impossible ni stupide, et je cherche juste à faire la même chose sur Windows Server/SQL Server (2012, les deux.)

Voila, encore une fois, merci d'avance de toute forme d'aide =)

[SQLpro]

Nous ne disposons pas de ces informations

Ce sont pourtant les informations cruciales et nécessaires pour tout projet de haute disponibilié... Les deux mesures à considérer sont :
Durée d'indisponibilité du système (combien de minute la production peut s'arrêter ?)
Durée de perte de production (temps pendant lequel le système a fonctionné mais dont les données n'ont pas été récupérée)
Ceci vous permettra de choisir les moyens de parvenir à votre but.
Enfin, la durée cumulée d'indisponibilité du système vous donnera le pourcentage de disponibilité. Par exemple avec un 99,999% vous ne disposez que de 5 minutes, 15 secondes par an d'interruption.

, le but étant simplement de créer un PIF d'une solution que le client pourra déployer lui-même.

C'est quoi un PIF ? jamais entendu parlé !

Bon, dans ce cas, je vais essayer d'expliquer le but de la demande.

Ce serait mieux !

Le client souhaite avoir à disposition une machine contenant une base de donnée sur SQL Server. En cas de crash de cette machine, il souhaite qu'une autre machine prenne le relai, avec le même contenu, les mêmes données.

C'est donc bien de la haute dispo...

Donc, la solution trouvé par la team qui m'a confié ce travail était la réplication peer-to-peer entre les deux machines...

Cette solution est parfaitement stupide et prouve que le "team" qui vous a mis sur cette voie ne connait rien en la matière et ferait mieux de se taire...
En effet, ceci est de la réplication de données. La réplication de données n'a rien à voir avec la haute disponibilité. En théorie il est possible d'utiliser la réplication de données pour faire de la haute disponibilité, mais c'est aussi stupide que de construire un gratte ciel avec des légos ! En effet la réplication des données est le fait de choisir parmi les tables d'une base A, les éléments de données à transmettre à la base B sachant qu'un élément est une extraction de la table disposant d'un filtrage horizontal (restriction avec la clause WHERE) et vertical (projection avec la clause SELECT). Le but de la réplication est soit de consolider/dispatcher certaines informations de certaines tables ou bien d'élargir la surface d'attaque d'une solution en présentant plusieurs serveurs dont certaines données sont communes, mais la plupart ne le sont pas (cas du gros site web marchand comme fnac.com, cdisount ou ventes privées...).
Si vous choisissiez une telle solution alors il faudrait répliquer table par table toutes les tables de la base et les ressources nécessaires pour faire cela écroulerait votre système !

J'ai déjà pu créé cette solution juste avant sur CentOS/MariaDB, une réplication Master/Master + failover, rien d'impossible ni stupide, et je cherche juste à faire la même chose sur Windows Server/SQL Server (2012, les deux.)

Votre erreur est de prendre pour exemple MySQL (que j’appelle MySQmerde tellement il y a de bugs et d'approximation dans ce pseudo SGBD non relationnel. À me lire : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux) En effet MySQL en est à l'âge de pierre en matière d’administration et de solution de haute disponibilité par rapport à Oracle ou SQL Server. Il vous aurait fallu tout simplement taper dans ne moteur de recherche les mots suivants : haute disponibilité "sql server". Et vous seriez immédiatement tombé sur cette page : https://msdn.microsoft.com/fr-fr/library/ms190202.aspx
Qui indique toutes les solutions valable (il y en a 4)...

Aujourd'hui la meilleure solution est AlwaysOn avec les groupes de disponibilité. Le pourcentage de disponibilité au niveau de SQL Server est de 100% et la perte de données est d'une durée de 0 car le système peut être mis en mode synchrone avec basculement automatique. Avec ce système, vous pouvez monter jusqu'à 4 "réplicas" dont 1 synchrone et les autres asynchrone. C'est cependant une solution couteuse : il vous faut l'édition Enterprise + la Software Insurance. En revanche, pas de paiement de licence pour les serveurs "froids". Si cela vous parait trop cher et qu'il n'y a qu'une seule base de production, alors, vous pouvez utiliser le mirroring de base de données qui ne nécessite que la version standard. Mais pour assurer le basculement automatique en mode synchrone, il vous faut un tiers (3e serveur SQL qui peut être une version gratuites - Express).

Bref, nous sommes à votre disposition si vous avez d'autres questions.

A +