Discussion :

[vinch999]

Salut,
J'ai un besoin que voici:

J'ai une database :
-Beaucoup d'écritures quasiment 24h/24
-Elle est d'un volume imposant
-Elle doit être hautement disponible (possibilité de récupération rapide avec des pertes minimisées en cas de crash)
-On doit faire du reporting dessus en parallèle (donc de la lecture)

A quelle stratégie pensez-vous avec ces infos? j'ai posté dans la partie réplication mais si vous avez d'autres idées...
(Réplication, mirroring, clusters, répartition de charge,...)

Merci pour l'aide !

[SQLpro]

Mirroring synchrone avec déport du reporting sur le miroir

A +

[vinch999]

Merci pour l'info, effectivement ça semble intéressant.

Quid si le serveur principal crash et que par malchance le mirroir crash aussi?
y aurait-il moyen de mettre un 3 ème serveur dans cette archi? Juste présent au cas où, voir même de faire du load balancing entre celui-ci et le principal afin d'optimiser le tout.

Ou alors :
-1 serveur principal
-1 serveur en backup si crash du principal
-1 mirroir du principal pour reporting

Afin de ne pas surcharger le mirroir si crash du principal

[darkelend]

Mirroring synchrone avec déport du reporting sur le miroir

Je pensais que les bases "mirrorées" n'étaient pas accessible en lecture. Et justement que c'était un des plus du "Always On" de rendre les bases "secondaires" accessibles en lecture.

[SQLpro]

Merci pour l'info, effectivement ça semble intéressant.

Quid si le serveur principal crash et que par malchance le mirroir crash aussi?
y aurait-il moyen de mettre un 3 ème serveur dans cette archi? Juste présent au cas où, voir même de faire du load balancing entre celui-ci et le principal afin d'optimiser le tout.

Ou alors :
-1 serveur principal
-1 serveur en backup si crash du principal
-1 mirroir du principal pour reporting

Afin de ne pas surcharger le mirroir si crash du principal

Avec AlwaysOn vous pouvez faire un double voir un triple mirroring. par exemple un miroir synchrone local à basculement automatique plus un miroir asynchrone à basculement manuel.

A +

[SQLpro]

Je pensais que les bases "mirrorées" n'étaient pas accessible en lecture. Et justement que c'était un des plus du "Always On" de rendre les bases "secondaires" accessibles en lecture.

Elle sont lisible depuis la version 2005 si vous faites un snapshot de la base. mais c'est unen photo à l'instant t.
A partir de 2012 vous pouvez faire des lectures dynamique directement sur le miroir.

A +

[vinch999]

Avec AlwaysOn vous pouvez faire un double voir un triple mirroring. par exemple un miroir synchrone local à basculement automatique plus un miroir asynchrone à basculement manuel.

A +

Cette fonctionnalité n'est disponible que depuis la version 2012, non?

[vinch999]

Elle sont lisible depuis la version 2005 si vous faites un snapshot de la base. mais c'est unen photo à l'instant t.
A partir de 2012 vous pouvez faire des lectures dynamique directement sur le miroir.

A +

Cela ne m'arrange pas spécialement, car théoriquement le reporting doit se faire avec des données synchros.

[SQLpro]

Cette fonctionnalité n'est disponible que depuis la version 2012, non?

Oui.

[SQLpro]

Cela ne m'arrange pas spécialement, car théoriquement le reporting doit se faire avec des données synchros.

Dans ce cas migrez vers le version 2012 !

Maintenant c'est quoi les métriques sur :

• Beaucoup d'écritures quasiment 24h/24
• Volume imposant
• Reporting dessus en parallèle (donc de la lecture)

Si vous êtes à plusieurs To, plus de 5000 transactions par seconde et avec plusieurs milliers d'utilisateurs, là oui, le mieux serait deux serveurs. Sinon un seul serveur un peu costaud suffit avec la version Enterprise et les bons réglages (sp_configure, mais aussi isolation snapshot, et resources governor...)

A +

[vinch999]

Dans ce cas migrez vers le version 2012 !

Maintenant c'est quoi les métriques sur :

• Beaucoup d'écritures quasiment 24h/24
• Volume imposant
• Reporting dessus en parallèle (donc de la lecture)

Si vous êtes à plusieurs To, plus de 5000 transactions par seconde et avec plusieurs milliers d'utilisateurs, là oui, le mieux serait deux serveurs. Sinon un seul serveur un peu costaud suffit avec la version Enterprise et les bons réglages (sp_configure, mais aussi isolation snapshot, et resources governor...)

A +

Plus facile à dire qu'à faire concernant la migration , ce n'est pas de mon ressort. va falloir faire avec 2008R2 malheureusement.
Concernant les métriques, je n'ai pour le moment pas ces infos.
Je sais juste que le nombre de users devrait être réduit, donc assez peu de lecture, théoriquement. Par contre beaucoup d'écriture. Mais dans des volumes tout de même raisonnables (plutôt de l'ordre du Go que du To)

Merci pour l'aide en tous cas !

[SQLpro]

Alors avec un bon serveur, pas mal de RAM et surtout un "smart array" avec au moins 8 disques, vous devriez vous en sortir.

En ce qui concerne les transactions, le plus important est le niveaux de RAID (exclure RAID 5, 6 et toutes combinaisons 50, 60), la ventilation des IO sur différentes agrégats et le parallélisme.

A +

[salva257]

Alors avec un bon serveur, pas mal de RAM et surtout un "smart array" avec au moins 8 disques, vous devriez vous en sortir.

En ce qui concerne les transactions, le plus important est le niveaux de RAID (exclure RAID 5, 6 et toutes combinaisons 50, 60), la ventilation des IO sur différentes agrégats et le parallélisme.

A +

Un bon serveur est une notion relativement floue...

Est-ce que la réplication transactionnelle ne pourrait répondre à ce genre de besoin en répartissant la charge sur 2 ou 3 nœuds? Cela permettrait aussi d'avoir des serveurs un peu moins bon...

[SQLpro]

Un bon serveur est une notion relativement floue...

Est-ce que la réplication transactionnelle ne pourrait répondre à ce genre de besoin en répartissant la charge sur 2 ou 3 nœuds? Cela permettrait aussi d'avoir des serveurs un peu moins bon...

Non, c'est stupide ! Avant de faire du scale out qui vous coutera TRES CHER (en matériel, en licence et en administration...), on commence par faire du scale out.

Un serveur SQL peut supporter 32 000 connexion simutanées. N'est-ce pas suffisant ?

la réplication d'une base entière en mode synchone va consommer entre 80 et 99% des CPU; Vous n'aurez donc plus aucune ressources pour les utilisateurs...

le but de la réplication est plus pensé pour répartir les données et non redonder. mais pour répartir il faut quand même quelques données communes...
Exemple : fnac.com
1) 16 serveur en Front office dont chacun comprend tous les produits, mais 1/16e des clients, commandes...
2) réplication des produits du BO vers le FO deux fois par jour (midi et minuit)
3) réplication des commandes toutes les 5 minutes du FO vers le BO

A +



A +

[mikedavem]

Un bon serveur est une notion relativement floue...

Est-ce que la réplication transactionnelle ne pourrait répondre à ce genre de besoin en répartissant la charge sur 2 ou 3 nœuds? Cela permettrait aussi d'avoir des serveurs un peu moins bon...

Effectivement la notion de "bon serveur" est à corréler avec la charge qui sera appliquée et les besoins en ressources (CPU, IO, RAM, réseau ...).

Cependant la mise en place d'une réplication transactionnelle dans ce cas n'est pas forcément judicieuse car elle requiert une administration beaucoup plus poussée et elle n'est pas forcément transparente au niveau applicatif (certains prérequis doivent être validés au niveau du schéma). De plus à la vue des contraintes de ha et de Reporting la réplication transactionnelle ne serait pas forcément la bonne candidate.

++