Discussion :

[rapido]

Bonjour,

Je cherche à mettre en place une architecture qui me permettra d'être évolutif en fonction de la montée en charge de mon application.
J'ai étudié différentes solutions qu'offre sql server 2005, telles que le mirroring et le clustering mais aucunes de ces solutions ne me conviennent, car elle offre de la haute disponibilité, mais pas de load balancing.

Quel solution technique puis-je mettre en place pour gérer le load balancing ?

[cavo789]

Juste une question, stupide peut-être : es-tu certain de devoir mettre en place une solution de ce style ? A quelle charge t'attends-tu ? Lorsque tu l'auras explicité, il y aura certainement un PRO en SQL Server pour t'indiquer la meilleure manière de travailler.

[kagemaru]

bonjour,

il me semble qu'existe quelques outils tierce partie pour réaliser ce genre d'architecture, souvent basé sur de la réplication ; cela devient rapidement une usine à gaz.

Je n'arrive pas à trouver de références sur ces outils, il y a des chances qu'ils n'ait pas bcp de succès...

SQL Server ne propose pas de solution de load balancing...

sauf pour des bases en lecture seule, dans un but de reporting (http://support.microsoft.com/?scid=k...0378&x=14&y=16)

[rapido]

J'ai actuellement la charge suivante :
500 000 INSERT par jour
15 000 000 SELECT par jour

Je pense que d'ici quelques mois, la charge aura doublée, voir triplée.

Nous utilisons actuellement le NLB avec Sql Server 2000, qui s'occupe de gérer le load balancing sur la couche réseaux, mais celui présente le gros inconvénient de ne pas répartir sa charge lors d'une panne matériel d'un noeud du cluster.

Je trouve vraiment dommage que SQL Server 2005 ne gère pas le load balancing en natif.
Si des experts SQL passent par là, ce serait gentil de me donner votre avis sur la question

[kagemaru]

Je trouve vraiment dommage que SQL Server 2005 ne gère pas le load balancing en natif.

ça viendra ...

500 000 INSERT par jour
15 000 000 SELECT par jour

ça ne veut pas dire grand chose, cela va dépendre de la taille des enregistrements insérés, du nombre de lignes de retournés, de la qualité de code sql, du design de la base.

Si votre archi est déjà en production, il faut bien regarder comment elle se comporte actuellement (perf i/o disques, cache hit, conso cpu, requêtes lentes, etc.)

[rapido]

ça ne veut pas dire grand chose, cela va dépendre de la taille des enregistrements insérés, du nombre de lignes de retournés, de la qualité de code sql, du design de la base.

Je suis bien d'accord. Je voulais juste vous donner une petite idée du nombre de requêtes.

[SQLpro]

Actuellement les performances extrêmes obtenues sur SQL Server avec une seule machine sont de l'ordre d'un million de transactions par minute (TCP-C). Donc très loin de ce qui sera ta charge.

De plus les solution de, load balancing et autres clusterisation ont un coût matériel, licence et admin extrêmement élevés, ce qui fait que je ne les préconise jamais de prime abord et j'invite mes clients à passer sur du mirroring dont la simplicité à tous les niveaux et les performances en font une technique de choix pour assurer une haute dispo, voire, la possibilité d'utiliser le mirroir enn READ ONLY pour du reporting par exemple.

A +

[rapido]

le problème c'est que nous n'avons pas les moyens d'acheter un méga serveur quadri-processeur qui serait capable de suivre le sql server.

Nous avons adopté cette solution de NLB car cela nous permettait de répondre aux évolutions de charge en achetant des serveurs de moyenne gamme.