Discussion :

[yakiniku]

Bonjour,

Nous sommes en train de réfléchir pour repenser la mise en place de l'architecture déjà présente de nos bases de données.

Actuellement, nous avons 2 serveurs de bases de données SQL Server 2008 qui interagissent parfois entre eux à l'aide de linked server.


Après un premier debriefing, nous avons pensé scinder notre architecture en 2 afin de séparer la partie Backoffice et la partie Frontoffice : Le premier serveur pour le BO qui contiendrait toutes les tables et s'occuperait des MAJ/Ajout/Suppression et la partie FO avec vues indexées et procédure stockée. Les 2 serveurs seraient alors liés via LinkedServer.

Mais j'ai de sérieux doutes concernant la sécurisation et la rapidité d’exécution des requêtes si nos SGBD communiquent entre elles en permanence...

Nous avons aussi penser à une autre solution qui éviterait d'utiliser le LinkedServer : avoir un SGBD source pour le BO qui synchroniserait le SGBD cible utilisé pour le FO, mais cela risque de poser des problèmes de MAJ sur le FO et de charges serveurs je suppose...

Bref, j'aimerais avoir vos avis et critiques concernant ces solutions ou d'autres propositions si vous avez de meilleures idées.

[Philippe Robert]

Je n'aime pas cette idée

Quand une requête exécutée sur un serveur A demande des données du serveur B via serveur liés, les données sont temporairement stockée dans tempbd => augmentation du nombre d'IO.

J'ai déja eu l'occasion de tuner une procédure stockée faisant appel à des données d'un serveur lié. Et bien, cette requête ramenait tout le contenu de la table du serveur B vers A avant de faire sa clause WHERE !

Selon mon point de vue, le mieu est d'investir dans une bonne architecture disque, serveur et réseau, un solide modèle de données et un cluster pour la haute disponibilité

[mikedavem]

En fait tout dépend comment la requête est écrite.

Avec un nom en quatre parties il y a de grandes chances que le moteur décide de ramener l'ensemble de données du serveur distant pour effectuer les opérations localement.

En utilisant OPENQUERY cela permet d'exécuter la partie de la requête concernée sur le serveur distant AVANT de ramener les données sur le serveur local.

++

[Ptit_Dje]

Après un premier debriefing, nous avons pensé scinder notre architecture en 2 afin de séparer la partie Backoffice et la partie Frontoffice : Le premier serveur pour le BO qui contiendrait toutes les tables et s'occuperait des MAJ/Ajout/Suppression et la partie FO avec vues indexées et procédure stockée. Les 2 serveurs seraient alors liés via LinkedServer.

Qu'est ce que vous entendez par backoffice et frontoffice ?
Doit on comprendre transactionnel et reporting ?

Nous avons aussi penser à une autre solution qui éviterait d'utiliser le LinkedServer : avoir un SGBD source pour le BO qui synchroniserait le SGBD cible utilisé pour le FO, mais cela risque de poser des problèmes de MAJ sur le FO et de charges serveurs je suppose...

Bref, j'aimerais avoir vos avis et critiques concernant ces solutions ou d'autres propositions si vous avez de meilleures idées.

C'est le principe du datawarehousing...
C'est assez courant comme pratique et recommande pour ne pas affecter outre mesure les performances du systeme transactionnel avec de lourdes queries plutot analytiques.

Pourriez vous clarifier ?

[yakiniku]

Qu'est ce que vous entendez par backoffice et frontoffice ?
Doit on comprendre transactionnel et reporting ?

J'ai oublié de préciser que les données sont principalement utilisés dans le cadre de projet web, d'où la notion de Backoffice et de frontoffice : le backoffice équivaut à toute la partie d'administration des données qui est caché à l'utilisateur lambda, et le front office est tout simplement le site en production qui lui est utilisé par l'utilisateur lambda.

Je ne connais pas trop la notion de transactionnel et reporting par contre, donc je ne sais pas si ca correspond à ca.

En fait tout dépend comment la requête est écrite.

Avec un nom en quatre parties il y a de grandes chances que le moteur décide de ramener l'ensemble de données du serveur distant pour effectuer les opérations localement.

En utilisant OPENQUERY cela permet d'exécuter la partie de la requête concernée sur le serveur distant AVANT de ramener les données sur le serveur local.

++

Je ne connaissais pas Openquery, mais ca a l'air vraiment pas mal pour optimiser au maximum les échanges entre les 2 serveurs

C'est le principe du datawarehousing...
C'est assez courant comme pratique et recommande pour ne pas affecter outre mesure les performances du systeme transactionnel avec de lourdes queries plutot analytiques.

Je pensais plus à de la réplication de données.

[Ptit_Dje]

Quelles sont vos contraintes d'architecture ?
Le BO et le FO doivent-ils absolument être séparés ?

le backoffice équivaut à toute la partie d'administration des données qui est caché à l'utilisateur lambda, et le front office est tout simplement le site en production qui lui est utilisé par l'utilisateur lambda.

A priori vous pouvez tres bien realiser cela a l'aide de vues et de roles de securite definis pour soit le BO, soit le FO.
Ca vous evite d'avoir 2 serveurs.

Quel est votre regle en matiere de publication des données BO/FO ?
Est ce que c'est de l'instantané ?

[elsuket]

Bonjour,

Encore une fois, je crois que l'on oublie l'intérêt des schémas et la possibilité d'implication qu'ils peuvent avoir dans la gestion de la sécurité des données ...

D'autre part, par l'échange de données à travers le réseau, vous ajoutez du temps d'exécution ...

@++

[yakiniku]

Quelles sont vos contraintes d'architecture ?
Le BO et le FO doivent-ils absolument être séparés ?

A priori vous pouvez tres bien realiser cela a l'aide de vues et de roles de securite definis pour soit le BO, soit le FO.
Ca vous evite d'avoir 2 serveurs.

Le problème c'est qu'on a déjà actuellement 2 serveurs, du coup on réfléchissait à un moyen de les optimiser au maximum, mais faute d'avoir un dba sous la main, nous ne savons trop sur quoi partir. Donc non le BO/FO ne doivent pas forcément être séparés, c'est une idée pour mieux structurer nos données. (Personnellement, je pense que les vues sont faites pour ça et que c'est se compliquer la vie pour rien que de vouloir les séparer totalement, mais je voulais soumettre l'idée pour en débattre)

Quel est votre regle en matiere de publication des données BO/FO ?
Est ce que c'est de l'instantané ?

Je ne crois pas qu'on est besoin d'afficher des données provenant de la base instantanément, il peut y avoir quelques minutes de latence avant l'affichage des données.

Encore une fois, je crois que l'on oublie l'intérêt des schémas et la possibilité d'implication qu'ils peuvent avoir dans la gestion de la sécurité des données ...

J'avoue ne pas y avoir penser (il n'y a aucun schéma mis en place dans la BDD actuelle...), donc je vais me pencher la dessus

D'autre part, par l'échange de données à travers le réseau, vous ajoutez du temps d'exécution ...

C'est bien là le problème .

Une autre solution que je vois serait de laisser l'ensemble des données scinder sur 2 serveurs pour partager la charge et éviter les échanges entre serveurs, et optimiser le tout par des vues et une meilleure gestion de la sécurité (schéma, etc)

[Ptit_Dje]

1 seul de vos serveurs tient il completement la charge du BO et du FO ?

Si c'est le cas, pensez a mettre une solution de HA (cluster/miroir) en place plutot que de partir sur des complications bizarres pour utiliser vos 2 serveurs.
L'avantage sera que vous aurez une plus grande availability de votre site ce qui est loin d'etre negligeable d'apres moi !

[yakiniku]

1 seul de vos serveurs tient il completement la charge du BO et du FO ?

Si c'est le cas, pensez a mettre une solution de HA (cluster/miroir) en place plutot que de partir sur des complications bizarres pour utiliser vos 2 serveurs.
L'avantage sera que vous aurez une plus grande availability de votre site ce qui est loin d'etre negligeable d'apres moi !

Pour le moment nos applications web sont divisés en 2, chaque partie étant sur un des serveurs en vrac (FO/BO mélangés) avec très peu d'optimisation et des règles de sécurité par forcément au point, d'où l'envie de repartir sur des bases saines.

Cette solution de cluster/miroir me plait, mais la migration des bases ne pourra pas se faire d'un coup, et les applications actuellement en production devront fonctionner pendant la période de transition, donc je ne sais pas si cela sera possible de mettre cette solution en place...

[Ptit_Dje]

Je ne connais pas vos contraintes ni vos fenetres de maintenance.
En tout cas ce que vous souhaitez realiser s'apparente a un projet en soi.
On peut effectivement vous donner des pistes ici...

Par contre si vous souhaitez une analyse plus detaillee avec un plan de migration concret limitant le downtime et une realisation sur place, sans DBA dans votre societe, je vous conseille de faire appel a un consultant externe.

[yakiniku]

Je ne connais pas vos contraintes ni vos fenetres de maintenance.
En tout cas ce que vous souhaitez realiser s'apparente a un projet en soi.
On peut effectivement vous donner des pistes ici...

Par contre si vous souhaitez une analyse plus detaillee avec un plan de migration concret limitant le downtime et une realisation sur place, sans DBA dans votre societe, je vous conseille de faire appel a un consultant externe.

C'est sûr que ca serait l'idéal, mais nous n'avons pas les moyens de prendre un DBA ou faire appel à un consultant... Donc c'est à moi d'essayer de mettre en place une architecture qui soit la plus optimisé et la plus maintenable possible, avec mes compétences plus ou moins limités en SQL.

Est-il envisageable de mettre en place un cluster pour de nouvelles bases de données et laisser les anciennes bases dans leur coin pour faire une migration au fur et à mesure avec cette solution ?

[Ptit_Dje]

Ca depend de plein de choses.
Avez vous analyse les pre-requis pour la mise en place d'un cluster et pourquoi plutot cette solution que le mirroring ?

Comme j'ai vu plusieures fois cite sur ce forum:

DBA c'est un metier et ca ne s'improvise pas.

Et ici on est tres concretement dans un cas ou il vous faut un projet, une analyse de ce qu'il faut faire afin de determiner quelle solution sera la plus adaptee.
C'est pas un cas genre "Comment reduire la taille de mes logs?"

Pour faire un parallele, c'est un peu comme si vous postiez une question regardant votre sante sur un forum medical. Les reponses ne remplaceront pas une consultation chez un medecin/specialiste si votre cas est plus complexe qu'un mal de tete apres une soiree trop arrosee.

Si vous ne parvenez pas a degager de l'argent pour un projet, des formations, et/ou une analyse externe, vous pouvez toujours tenter l'auto-medication.

Je n'ai pas pour habitude de me lancer dans ce genre de reponse par contre je suis convaincu dans ce cas que c'est vraiment la meilleure chose a faire pour vous.

Cordialement.

[yakiniku]

Ca depend de plein de choses.
Avez vous analyse les pre-requis pour la mise en place d'un cluster et pourquoi plutot cette solution que le mirroring ?

Comme j'ai vu plusieures fois cite sur ce forum:

DBA c'est un metier et ca ne s'improvise pas.

Et ici on est tres concretement dans un cas ou il vous faut un projet, une analyse de ce qu'il faut faire afin de determiner quelle solution sera la plus adaptee.
C'est pas un cas genre "Comment reduire la taille de mes logs?"

Pour faire un parallele, c'est un peu comme si vous postiez une question regardant votre sante sur un forum medical. Les reponses ne remplaceront pas une consultation chez un medecin/specialiste si votre cas est plus complexe qu'un mal de tete apres une soiree trop arrosee.

Si vous ne parvenez pas a degager de l'argent pour un projet, des formations, et/ou une analyse externe, vous pouvez toujours tenter l'auto-medication.

Je n'ai pas pour habitude de me lancer dans ce genre de reponse par contre je suis convaincu dans ce cas que c'est vraiment la meilleure chose a faire pour vous.

Cordialement.

Ah mais je suis tout à fait d'accord, je suis développeur web à la base (donc je ne me prétends certainement pas dba) et mes supérieurs ne vont pas nous donner le budget et le temps pour pouvoir faire quelque chose d'optimal avec nos BDD... Tout ce que je peux faire, c'est essayer de limiter la casse et mettre en place quelque chose qui tienne la route...

C'est frustrant mais c'est comme ca, il faut croire que les entreprises n'ont toujours pas compris qu'être dba, c'était pas un métier que le premier mec venu sachant faire du sql peut prétendre.

Sinon pour le cluster/mirorring je pensais que les 2 pouvaient être mis en place dans la même solution ? (cf http://msdn.microsoft.com/fr-fr/library/ms191309.aspx)

[Ptit_Dje]

Effectivement, les 2 technologies peuvent etre combinees ensemble dans la meme solution.
Par contre il faut dans ce cas la compter au moins 4 serveurs. 2 par cluster et un lien (mirroir) entre les 2 clusters.

[SQLpro]

Si vous avez 2 machines distante (lien réseau) alors il est stupide de faire un couplage fort par serveur lié ou trigger par exemple.
Le seul intérêt d'avoir deux machines est que l'une puisse être à l'arrêt sans gêner le service de l'autre. C'est possible dans MS via 2 technologies :

• la réplication (MS SQL Server fournit 4 modes distinct : transactionnel, snapshot, fusion ou peer to peer).
• service broker (système de gestion de bases de données distribuées, transactionnelle, sérialisé et asynchrone)

Or vous avez choisit la plus mauvaise des solutions : un couplage synchrone qui ne permet aucune tolérance du système global (une machine en panne et out est en panne) en sus de générer des temps d'attente important (le réseau c'est ce qu'il y a de pus lent..)

La considération de séparer FO du BO est souvent une considération de volume transactionnel. par exemple à FNAC.COM il y a bien une séparation BO/FO avec réplication vu le nombre de transaction extrêmement élevé du site (l'un des tout premier site marchand).
Si ce n'est pas le cas chez vous, en plus d'être stupide techniquement, c'est couteux, car il vous faut payer 2 machines (hardware + licence + admin...)

Et si vos deux bases sont pour une même application, et que votre volume transactionnel n'est pas gigantesque, alors c'est du gâchis !
Mettez vos deux bases sur le même serveur.
Dans un premier temps, rerouter votre linked serveur pour qu'il pointe sur lui même
Dans un second temps, vous éliminerez ces linked serveur au profit de requêtes interbases.
Le mieux serait de tout intégrer dans la même base en conservant telle qu'elle l'une des bases et en plaçant l'aure dans un schéma SQL ayant le même nom que l'ancien nom de la base.
Pour votre ancien serveur, vous pourrez l’utiliser comme solution de haute dispo, par exemple en mirroring. Dans ce cas, aucune licence (Windows ou SQL Server) n'est à payer !

Mais comme on vous l'a dit, tout cela s'étudie...

C'est de l'architecture de données....

A +

[yakiniku]

Ok, merci pour vos réponses, ca m'a bien aidé à y voir plus clair dans tout ce bazar. Je mets en résolu !

Ciao