Discussion :

[bellak]

Salut tous le monde,

SVP, j'ai une mission de faire une étude comparatif sur les différentes méthodes sur la mise en haute disponibilité (automatiquement). j'ai lu beaucoup d'articles et discutions sur différents forum et j'ai encore des questions sur la tête.

1 : d’après ce que j'ai lu on ne peux pas (ou bien on ne dois pas) faire de la réplication sur les bases de données(source1,source2).

2 : on ne peux pas utiliser le Log Shipping a cause des basculements manuels (source)

donc il reste maintenant les deux autres solutions : Clustering et Mirroring

questions :
- tout d'abord quel est la méthode la plus fiable et garantie (pour qu'il n'y aura pas de perte de données)
- quel est la méthode la plus facile a exploiter

pouvez-vous me donner quelques references sur l'exploitation de chaque méthode ?

PS : on a 3 BDD trop volumineuses (voir 1 jusqu’à 3GO par semaine) sur 3 serveurs (serveur HP ProLiant ML350 G5). et on doit ajouter 1 serveur (ou bien 3 suivant l’étude) pour les 3 BDD miroirs
SQL Server 2005 Entreprise , Windows Server 2003 Entreprise
le cout n'est pas un problème en ce moment (que ce soit sur le cout des licences ou de matos)

merci a vous

[SQLpro]

1 : d’après ce que j'ai lu on ne peux pas (ou bien on ne dois pas) faire de la réplication sur les bases de données(source1,source2).

Le but de la réplication est de répliquer quelques données, pas des bases entières.

2 : on ne peux pas utiliser le Log Shipping a cause des basculements manuels (source)

Là vous faites erreur, car on peut automatiser le basculement, mais il faut écrire un petit applicatif pour cela.

- tout d'abord quel est la méthode la plus fiable et garantie (pour qu'il n'y aura pas de perte de données)

Fiable et garantie :
1) le clustereing, à condition d'avoir un matériel certifié MS Clustering Services et strictement identique entre les serveurs (à quelques bémols près), ainsi qu'une baie de disque répliquée car elle constitue le SPOF !
En pratique le basculement est de l'ordre de la minute.

2) le mirroring en mode synchrone a basculement automatique, à condition que la liaison entre les deux serveurs soit rapide et sans microcoupure.
En pratique le basculement est de l'ordre de quelques dizaines de secondes.

- quel est la méthode la plus facile a exploiter

Sans conteste le mirroring si les bases sont peu nombreuses et s'il y a peu de travaux de l'agent SQL. Sinon le clustering.
A lire : http://blog.developpez.com/sqlpro/p8...jobs-de-l-age/

A +

[bellak]

merci SQLpro pour la reponse

Là vous faites erreur, car on peut automatiser le basculement, mais il faut écrire un petit applicatif pour cela.

oui je sais , mais on veux eviter les codes (pour la raison de performance et pour qu’il n y aura pas une possibilité de perte de données)

j'ai lu sur une discutions qu'en cas de mirroring la BDD miroir est seulement en lecture seule ; est-ce que c'est vrai ? si oui est-ce qu'au basculement ou bien juste avant.

une autre petite question : le basculement se fait par Windows Server ou par SQL Server sinon un basculement hardware.

PS : on va pas utiliser le 2eme serveur qu'en cas de défaillance du 1er

[mikedavem]

j'ai lu sur une discutions qu'en cas de mirroring la BDD miroir est seulement en lecture seule ; est-ce que c'est vrai ? si oui est-ce qu'au basculement ou bien juste avant.

Non elle n'est pas en lecture mais dans un état de restauration. Pour pouvoir faire de la lecture il faut créer un snapshot sur la base de donnéesen en miroir.

une autre petite question : le basculement se fait par Windows Server ou par SQL Server sinon un basculement hardware.

PS : on va pas utiliser le 2eme serveur qu'en cas de défaillance du 1er

Si vous parlez du cluster, c'est l'OS qui gère le basculement .. le cluster se définit à ce niveau. En revanche si vous parlez du mirroring c'est le mécanisme de mirroring propre à SQL Server qui gère la bascule.

++

[bellak]

merci a vous deux,

SVP, pouvez-vous me donner quelques references sur l'exploitation de mirroring et des sources vu qu'il y aura quelques codes sur le mirroring

encore merci

[slefevre01]

Bonjour,
il y a aussi des produits de réplication comme DoubleTake.
C'est de la réplication d'I/O un peu comme DRDB sous Linux.
On réplique les répertoires ou se trouvent les bases de données. Par contre, il faut que les services SQL soient arrêtés sur le serveur de secours.

Ca gère les failover automatiques par bascule d'adresses IP en quelques secondes.
C'est un produit très fiable que j'utilise pour qq clients.

Seb

[SQLpro]

Sur DoubleTake :
Sauf que c'est horriblement couteux alors qu'avec 2005 tout est inclus, qu'en sus c'est extrêmement compliqué à mettre en œuvre (nécessité de faire evenir les gens de doubletake au prix fort) et pas si fiable que cela (un de mes clients en a fait l'amère expérience..).

A +

[slefevre01]

Je ne connais pas les prix mais c'est surement moins cher qu'un cluster MS.
Le mirroring ou logshipping c'est bien pour 10 bases max à gérer, quand vous avez plus de 100 bases sur un serveur, c'est autre chose.

Je dois être un expert car je l'ai mis en place en une demi journée sans support DT et ca marche sans pb depuis 4ans. Franchement, ce n'est pas compliqué.

Seb

[SQLpro]

Je ne connais pas les prix mais c'est surement moins cher qu'un cluster MS.

Vous avez tout faux, car que ce soit le mirroring, ou le clustering, c'est entièrement gratuit.
En effet, dans le modèle de paiement de licences de Microsoft, vous n'avez aucune licence à payer, ni Windows, ni SQL Server pour les serveurs inactifs dans le cadre d'une haute disponibilité. En sus le mirroring est intégré à SQL Server sans coût supplémentaire et le clustering est inclus à partir de la version Enterprise jusqu'à 16 noeuds.
Alors que dans votre solution Doubletake, vous avez à payer à la fois le service DoubleTake, la licence Windows et la lcence SQL Server....

A !

[slefevre01]

un cluster sql est cher au niveau hardward dans le sens ou il faut une baie de stockage (DAS ou SAN)

[zinzineti]

un cluster sql est cher au niveau hardward dans le sens ou il faut une baie de stockage (DAS ou SAN)

Bonjour,

Peux-tu nous dire au niveau hardware ce que tu as comme hardware pour mettre en place la solution DoubleTake ?

Quel est le nombre de serveurs et leurs caractéristiques de chaque serveur dans ton cas ?

Merci pour ce retour.

[slefevre01]

Il faut juste un serveur SQL de PROD et un serveur SQL de Secours de configuration identique surtout au niveau architecture disque.
1 câble croisé entre les deux serveurs pour le traffic de réplication DT car il ne doit pas y avoir de latence réseau.

Pas besoin de serveur témoin pour le failover. C'est le serveur de secours qui surveille le maître et déclenche le failover, avec bascule d'ip et démarrage des services SQL sur le secours.

Au niveau licence SQL, je pense qu'une seul licence est nécessaire car les services SQL sont arrêtés sur le secours.

Seb

[zinzineti]

Celà veut dire que le serveur de secours surveille juste ce qui se passe au niveau réseau ou OS mais ne sait pas détecter les problèmes au niveau SQL Server (services, bases inaccessible, ...) ?

En d'autre terme si par exemple j'arrête le service SQL sur le serveur primaire,
est ce que la solution Doubletake peut détecter cette anomalie et basculer sur le serveur secondaire ?

[slefevre01]

Celà veut dire que le serveur de secours surveille juste ce qui se passe au niveau réseau ou OS mais ne sait pas détecter les problèmes au niveau SQL Server (services, bases inaccessible, ...) ?

Oui, il ne fait que pinguer le master

En d'autre terme si par exemple j'arrête le service SQL sur le serveur primaire,
est ce que la solution Doubletake peut détecter cette anomalie et basculer sur le serveur secondaire ?

Non, il ne va pas jusque là. A moins qu'on puisse le scripter, je ne sais pas.

Il faut donc le coupler avec un autre outil de monitoring.

Seb

[zinzineti]

Oui, il ne fait que pinguer le master



Non, il ne va pas jusque là. A moins qu'on puisse le scripter, je ne sais pas.

Il faut donc le coupler avec un autre outil de monitoring.

Seb

Merci pour les infos

A+

[mikedavem]

Il faut juste un serveur SQL de PROD et un serveur SQL de Secours de configuration identique surtout au niveau architecture disque.
1 câble croisé entre les deux serveurs pour le traffic de réplication DT car il ne doit pas y avoir de latence réseau.

Effectivement en surface même principe que le mirroring. Avec double take on est au niveau réplication I/O pour le serveur alors qu'avec SQL Server nous sommes au niveau transaction pour une base de données.

De plus il ne me semble pas que double take permette de récupérer une partie du cache des données sur le serveur en miroir lors du basculement.
Cependant c'est un produit qui fonctionne plutôt bien une fois paramétré.

Pas besoin de serveur témoin pour le failover. C'est le serveur de secours qui surveille le maître et déclenche le failover, avec bascule d'ip et démarrage des services SQL sur le secours.

.

Avantage ici pour double take. D'ailleurs avec la future version de SQL Server ce problème sera également réglé. Plus besoin de serveur témoin pour le basculement.

Au niveau licence SQL, je pense qu'une seul licence est nécessaire car les services SQL sont arrêtés sur le secours.

Oui en principe une seule licence suffit tant que le serveur en miroir se cantonne à ce rôle. Dès lors que l'on veuille faire du reporting (et donc avoir un accès en lecture via les snapshot) sur ce 2eme serveur (scénario courant), il faut avoir une 2eme licence.

Je tiens à préciser tout de même qu'une solution basée sur le mirroring SQL Server est moins coûteuse qu'une une solution basée sur double take.

A+

[SQLpro]

Attention, dans le cas de DoubleTake, deux remarques :
1) il faut payer la licence Windows, alors que pour le clustering, log shipping ou mirroring, cela n'est pas exigé ! En fait DoubleTake est considéré dans ce cas comme un soft de production...
2) un problème peut survenir et la base de données peut être perdue, si l'on utilise des caches en écriture sur les baies de disque.

NOTA
Aujourd'hui les système de copie par IO sont en général un second secours après le clustering ou après le mirroring.

ATTENTION :
Microsoft recommande (et prenez le pour acquis) de ne pas dépasser 10 bases minorées. Au delà, prendre le clustering. En sus dans la version standard un seul thread et mirroring synchrone est possible. La version Enterprise permet le multithreading des miroirs et l'asynchrone.
Cela dit, la meilleure des optimisation reste 1 base sur 1 serveur. Seules certaines conceptions d'applications peut orthodoxes utilisent le multibase !
(Comment, par exemple, sauvegarder des données de manière synchrone lorsque l'on a plusieurs bases pour une même application ???)


A +

[bellak]

merci a tous ,
donc pour les 3 serveurs BDD doit-on utiliser un seul serveur de BDD miroir ou bien 3 serveurs ??