Discussion :

[yahoo]

Bonjour,

Nous sommes en train de voir comment mettre en place un systeme de replication d'une BDD SQL Server 2000 (si besoin nous migrerons vers 2005). Nous hesitons entre une replication par transaction ou bien par fusion et avons besoin d'avis d'expert.

Quelques details:
- la BDD fait environ 300 GO aujourd'hui et devrait faire environ 1TO d'ici 1 an ou 2.
- Le nombre de nouveaux enregistrement par jour est entre 1 a 10 millions
- la BDD est en acces depuis un site internet et environ depuis 30 applications windows par les usagers internes.

A ce jour, nous sommes satisfait des performances de notre server. On a un serveur de secours qui est mis a jour 1 fois par semaine. Nous souhaitons que ce serveur de secours soit "continuellement" a jour. De plus si nombre d'utilisateurs internet explose je crains que le serveur SQL (sur une machine 32 bits) n'arrive plus a suivre. Mes premieres 2 questions sont donc :
- Pour de telles demandes SQL server 64 bits (avec donc bien de plus de RAM) est-il plus rapide en general pour faire des INSERT ? C'est en effet l'ecriture des donnees qui nous parait le plus problematique plus que les performances des SELECT.
- Devons-nous nous orienter vers une replication par fusion pour faire du load balancing plutot qu'une replication par transaction ?

Une autre question que nous nous posons est comment faire pour que les developpeurs ne galerent pas avec les Connection string pour acceder a la base. Voici les pistes discutees jusqu'a present :

- Avec ADO.Net et la technologie Mirroring (SQL Server 2005) on peut specifier 1 unique serveur Failover ce qui n'est pas genial mais est mieux que rien. Mais sous ADO (et donc Delphi win32) la notion de Failover n'existe pas. De plus Mirroring => 2 machines seulement dont une qui en pratique fait TOUT c'est a dire il n'y a pas de load balancing. Est-ce exact ?

- Modifier le code de sorte a ce que l'on fasse de partout:
oConn.ConnectionString = "server=X...";
try
oConn.Open();
catch
oConn.ConnectionString = "server=Y...";
oConn.Open();
end;
Or cela ne marche pas avec les pages ASP.NET et les SqlDataSource car ils lisent la connection string depuis le web.config file

- Avoir un service windows qui teste la connection a SQL server regulierement. Si la connection ne peut etre etablie changer la connection string dans le fichier web.config et ailleurs. Mais la encore on n'utilise en pratique qu'une seule machine pour SQL tout le temps et il n'y a pas de load balancing.

Donc l'autre question que nous nous posons est de savoir comment mettre en place une strategie de replication pour que les developpeurs et le support ne galere pas avec les connection string et etre sur que le load balancing soit efficace.

Toute idee, piste, livre a acheter (en anglais de preference), etc est la bienvenue.

Merci,
Michael

[SQLpro]

La réplication n'est absolument pas faite pour avoir un serveur de secours. L'intérêt de la réplication réside dans le fait de mettre à disposition un sous ensemble d'information sur un serveur distant par rapport à une base complète.

Par exemple répliquer les factures depuis le site marchand vers la base comptable.

La réplication est aussi très couteuse en terme de process, surtout si l'on demande un temps de latence le plus court possible.

Nous souhaitons que ce serveur de secours soit "continuellement" a jour.

Cela veut donc dire haute disponibilité...
Dans ce cas différentes méthodes sont possible, parmi lesquelles le log shipping, le clustering ou le mirroring. Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/s...disponibilite/

- Pour de telles demandes SQL server 64 bits (avec donc bien de plus de RAM) est-il plus rapide en général pour faire des INSERT ?

Bonne question : hélas non, sauf si votre besoin en RAM est colossal. En effet dans un OS 64 bits il faut convertir à l'écriture les données en 32 bits car les disques ne sont pas encore nativement en 64 bits. D'où un ralentissement des écritures....

- Devons-nous nous orienter vers une réplication par fusion pour faire du load balancing plutôt qu'une réplication par transaction ?

Ceci est un autre problème. Vous mélangez haute disponibilité et montée en charge (scaling). Ce sont deux problématique totalement différentes...

Il faut comprendre que toute montée en charge externe est bien plus couteuse à tous niveaux que l'upgrade du serveur. On a l'habitude de dire qu'il faut épuiser le scale in avant de faire du scale out.
Autrement dit avant de prendre un second serveur, il faut avoir épuiser le premier par ses limites physiques : 64 processeur, 64 Go de RAM, 32 disque en baie SAN...

Pour de telles solution, il y a, outre la réplication, la fédération de serveur (partitionnement des données sur n serveur avec travail sur vue d'agrégation).


Pour étudier cela il faut calculer les dimensions de 3 choses importante :
1) la fenêtre des données, qui va dimensionner la quantité de RAM nécessaire
2) le volume transactionnel (nombre d'utilisateurs simultané / durée moyenne des transactions) qui va donner le nombre de processeurs et de carte réseau
3) le volume globale des données et des index (du journal et de la tempdb) qui va permettre de structurer le nombre et la forme des agrégats disques.
Avez vous entrepris une telle étude lors du choix de votre serveur ?

Parce que si vous pensez que plusieurs serveur c'est mieux, alors là vous vous trompez lourdement :
1) c'est plus coûteux en licences (Système et SQL)
2) c'est plus couteux en administration (2 fois plus de boulot)
3) globalement le système à plus de risque de tomber en panne (deux machines au lieu d'une font baisser le MTBF)

Une autre question que nous nous posons est comment faire pour que les developpeurs ne galèrent pas avec les Connection string pour accéder a la base

Tout ceci se résoudra lorsque vous sera clair dans votre tête. Par exemple si vous choisissez le mirroring de bases de données, il y a un paramètre à rajouter dans votre chaine de connexion et dès lors le basculement peut être totalement automatique.

CONCLUSION :

Architecturer une telle solution demande une étude préalable sérieuse car les coûts si l'on se trompe sont énormes et justifieront votre départ anticipé en cas d'insatisfaction...

Je vous invite à lire préalablament les articles que j'ai écrit sur l'optimisation des serveurs SQL :
http://sqlpro.developpez.com/optimisation/

Ensuite, contactez moi, si vous le voulez pour discuter de vos diverses possibilités. Il se trouve que j'ai un peu de temps entre 10h et midi ce jour !
Vous trouverez mes coordonnées sur mon site d'entreprise :
http://www.sqlspot.com

A +

[yahoo]

Bonjour et merci bien pour cette excellente reponse.
Le mirroring semble etre la solution la mieux adaptee a nos besoins. Son seul default concerne nos applications delphi win32 pour lesquelles le switch n'est pas automatique.

Bien a vous,
Michael

[SQLpro]

C'est possible si vous utilisez un alias de connection qui passe par SQLNCLI.

A +