Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Un seul et meme disque pour plusieurs Tempdb?
Bonjour,
Je dispose d'un nouveau serveur avec plusieurs instances, et selon les Best Practice Microsoft SQL, il est recommandé de placer la base de données "Tempdb" sur une disque rapide à part.
Ma question est :
-Est-il possible de dédier un seul est même disque pour tout les "Tempdb" des instances présentes sur mon seveur sans que cela n'affecte les performances (qui est le but recherché)?
Merci pour vos réponses
Il me semble que tu saches déjà que cela va forcement affecter les performances de ton applications.Si c'est pour une utilisation pro et si vos budgets, respecter les recommandations de l'éditeur.
Vous avez plusieurs instances sur le même serveur?pour tout les "Tempdb" des instances présentes sur mon seveur
Combien de disque peux-tu disposer et combien d'instance veux tu installer ?Envoyé par Tuxoon
-Est-il possible de dédier un seul est même disque pour tout les "Tempdb" des instances présentes sur mon seveur sans que cela n'affecte les performances (qui est le but recherché)?
Merci pour vos réponses
Est-il possible de dédier un seul est même disque pour tout les "Tempdb" des instances présentes sur mon seveur sans que cela n'affecte les performances (qui est le but recherché)?
Clairement un disque physique dédié pour chaque tempDB vous apportera de meilleurs performances qu'un disque partagé pour vos multiples tempdb...
Bonjour,
Merci a tous pour vos reponses
Il va y avoir au moins 5 instances voir plus. Apres reflection, il se trouve que l'on va partager ces instances entre deux serveurs mises en cluster multi-site (voir trois dans un avenir prochain) .
Pour le basculement des services, je me suis rendu compte qu'il est preferable (obligatoire) qu'un disque dedie a "Tempdb" par instance soit cree.
Heureusement, nous avons enormement d'espace disques!
Merci encore pour vos eclairsissement qui me seront utiles prochainement.
Bonne journee a tous
Bonjour,
Précision : on parle bien de disque physique...
Si ce n'est pas indiscret, pourquoi avez vous autant d'instances ?Il va y avoir au moins 5 instances voir plus
Pour le basculement multi-site, il vaux mieux utiliser le mirroring des bases de données. Je ne crois pas qu'il soit possible de faire du cluster multi-site sous windows !Bonjour,
Merci a tous pour vos reponses
partager ces instances entre deux serveurs mises en cluster multi-site (voir trois dans un avenir prochain) .
Pour le basculement des services
Bonne journee a tous ;
Detrompes toi l'ami
Un peu de lecture:
http://download.microsoft.com/downlo...erCluster.docx
Tu peux y trouver une section multi-site failover cluster (page 15).
@Tuxoon:
Si jamais tu as un retour d'experience a partager la dessus, il est tres bienvenu
Re-bonjour
Concernant l'espace disque, nous disposons de SAN HP.
Toutes les données se trouvant sur le SAN du site A sont automatiquement repliquées sur le SAN se trouvant sur le site B (le process de replication est effectué par la technologie HP).
L'installation d'un cluster Microsoft SQL multi-site est identique a celle d' un simple cluster, si ce n'est que pour le Quorum nous utilison un File Share Witness (Node and File Share Majority), soit une simple dossier partagé sur un troisième serveur, de préférence sur un troisième site.
La partie qui pourrait être la "plus compliquée"concerne la configuration réseau au niveau de la redondance.
Voici un lien interressant sur la mise en place d' un cluster SQL multi-site :
http://clusteringformeremortals.com/...%80%93-part-1/
Dans ce lien, l'application permettant la réplication s'appelle DataKeeper.
Concernant le nombre d'instance, elle correspond au nombre d'application.
Les applications ayant un grand nombre de bases de données (on en a plusieurs) ont leur propre instance (SharePoint par exemple).
Concernant "les différentes applications ayant peu de petites bases de données", elles sont toutes regroupés sur la même instance.
Bonne journée
Concernant le nombre d'instance, elle correspond au nombre d'application.
Les applications ayant un grand nombre de bases de données (on en a plusieurs) ont leur propre instance (SharePoint par exemple).
Concernant "les différentes applications ayant peu de petites bases de données", elles sont toutes regroupés sur la même instance.
Il est déconseillé d'avoir plusieurs instances sur un même serveur physique...
Préférez 5 serveurs pour vos 5 instances ou reconsidérez le fait de répartir vos bases sur des instances différentes (en plaçant donc les différentes bases sur une même instance)
Merci Iberserk, j'attendais ce genre de reponse.
Etant admin systeme et reseau a la base, depuis quelques temps l'on m'a donner la charge des server SQL, j'ai trouver ce genre d'installation a mon arrivee dans l'entreprise.
Apparement, le but aujourd'hui est de diminuer le nombre de serveur SQL physique, en migrant plusieurs instances sur un cluster a 2 ou 3 noeuds, chaque noeud ayant une tres bonne config (72 voir 140 GB de RAM ou + si besoin est, system a 6 coeurs, 12 processeurs logiques, avec SAN HP ayant de tres bonnes performances).
J'ai un peu moins d'une dizaine d'instances reparties sur plusieurs serveurs (en cluster et en standalone) et plus de 200 DB.
Ayant tres peu de connaissances SQL, j'essai de rechercher toutes les informations importantes concernant l'optimisation d'un serveur SQL (au niveau du system) et il est vrai que je n'ai jamais vue une documentation concernant la presences de plusieurs instances sur un seul et meme serveur.
Je vais tres prochainement solliciter vos precieux conseils dans d'autres topics
Malheureusement, je ne penses pas que mes responsables voudront augmenter le nombre de serveur SQL par instance. Je devrai prouver cette utilitee en prouvant que les performances sont moins bonnes. J'ai commencer a creer une baseline concernant tous les serveurs SQL qui pourra m'etre utile pour ca
Merci encore pour vos conseils
C'est inutile d'avoir une instance par serveur physique si le serveur a la capacite d'en contenir plusieures ! Gaspillage de ressources... A moins de contraintes legales ou techniques specifiques.
Apres il faut par contre bien delimites les ressources disponibles pour chaque instance (min-max de RAM, CPU par exemple en utilisant WSRM) et aussi leur laisser leurs propres disques histoire de savoir monitore l'usage des ressources par instance independemment.
Selon certaines contraintes on peut devoir separer plusieurs bases de donnees/applications car celles-ci demande des droits trop eleves sur une instance (imagine une application qui necessite sa sur une instance... Et bien il vaut mieux la foutre seule sur une instance au niveau securite car elle pourrait potentiellement foutre la grouille sur toute l'instance).
Apres, comme souvent, il n'y a pas une mais des solutions et une analyse plus en detail de ce que vous hostez comme bases/application devrait vous permettre de voir plus clair comment vous pourriez consolider vos serveurs.
C'est toujours un absurdité à tous les niveaux d'avoir plusieurs instances sur un même serveur physique :
1) il y a concurrence de mémoire et le réglage possible étant statique, la RAM est très mal utilisée.
2) un certain nombre de ressources redondantes sont utilisées
3) il y aura concurrence des CPU à moins de l'interdire par un masque d'affinité différente et sans chevauchement pour chaque instance
4) les verrous mémoire seront important et les temps d'attente log...
Bref, totalement contre performant.
Si vous voulez de la performances, c'est 1 instance par serveur physique et pas de virtualisation. En sus vous devez maitriser la gestion des agrégat RAID dans votre SAN en évitant le RAID 5 / 6 et en alignant les LUN sur des disques physiques.
Enfin, croisez les fichiers data et log des bases pour répartir la synchro des IO
Lisez les articles que j'ai écri à ce sujet sur mon site et notamment :
http://blog.developpez.com/sqlpro/p8...t-le-stocakge/
http://blog.developpez.com/sqlpro/p9...u-plusieurs-1/
A +
Pas du tout d'accord comme viens de l'expliquer SQLPRO c'est justement dans le cas ou vous allez tenter de partager ces ressources que vous allez au devant de problème...C'est inutile d'avoir une instance par serveur physique si le serveur a la capacite d'en contenir plusieures ! Gaspillage de ressources...
Bonjour a tous et merci pour ces liens.
a vous lire, je penses avoir pas mal de de lecture et de boulot pour que mon parc de serveur SQL soit correctement configurer.
Merci encore et bonne journee
Si vous avez 16 Go sur le serveur Physique (64 bits), vous allez par exemple donner 8 Go pour une instance et 8 Go pour l'autre via sp_configure.
Problème si l'une des instance à besoin de beaucoup plus alors que l'autre ne bosse pas, la première sera toujours limité à 8 Go. Tandi que l'autre à aussi 8 Go pour rien ! C'est une absurdité !
Si vous laissez les deux serveur se partager la RAM alors l'un va vampiriser la RAM de l'autre et vous pouvez arriver dans une situation instable au niveau RAM : l'un aura toute le RAM et l'autre rien (SQL Server étant préemptif au niveau RAM). Ce qui fait que l'autre instance devra signaler un stress mémoire à l'OS qui arbitrera et demandera à l'autre instance de rendre de la RAM, opération qui ne pourra pas être effectué immédiatement si une grosse transaction est en cours. Der plus la mémoire redonnées risque d'être reprise très rapidement si l'autre instance ne bosse plus trop.
De plus les méta données sont dédoublées, DMV, profileur interne, etc... donc deux fois plus d'encombrement mémoire
A +
Est ce que l'on ne se retrouve pas dans la même situation avec une instance et plusieurs bases de données applicatives ? Une application qui sera plus gourmande en ressources pendant un intervalle de temps indéterminé va vampiriser également la mémoire au détriment des autres applications ...Si vous avez 16 Go sur le serveur Physique (64 bits), vous allez par exemple donner 8 Go pour une instance et 8 Go pour l'autre via sp_configure.
Problème si l'une des instance à besoin de beaucoup plus alors que l'autre ne bosse pas, la première sera toujours limité à 8 Go. Tandi que l'autre à aussi 8 Go pour rien ! C'est une absurdité !
On pourrait dire d'utiliser le gouverneur de ressources dans ce cas mais la réservation de la mémoire se fait de manière statique également .. ce qui est alloué le reste .. on se retrouve bien dans la même situation que pour 2 instances.
Bon le gros désavantage comme tu le dis c'est que chaque instance a besoin de son propre espace mémoire de travail ... et l'administration est plus complexe .. 2 instances à gérer au lieu d'une. Dans ce cas il faudrait pouvoir avoir des métriques d'utilisation des ressources pour chaque application qui sera hébergé sur chaque instance + une éventuelle marge afin de déterminer le dimensionnement et le paramétrage nécessaire aux différentes ressources comme l'a évoqué Ptit_Dje.
Si on revient au problème de Tuxxon effectivement avoir plusieurs instances dans son cas n'est peut être pas nécessaire. Mais dans le cas où ceci serait obligatoire, dois t'on forcément garder 2 serveurs physiques avec une instance dédiée même si les ressources utilisés ne dépassent pas le 1/3 des ressources totales ou consolide t'on sur un seul serveur physique avec 2 instances avec paramétrage correct ?
++
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager