Discussion :

[Magohamoths]

Bonjour,

Que pensez-vous du thread de ce forum, citation et lien ci-dessous.
Sur internet je n'ai retrouvé aucune référence, en anglais ou en français.

Re: SQL Server 2008 sur un contrôleur de domaine : possible ?

Messagepar Timil sur Jeu 19 Nov 2009, 21:51
Impossibilité d'authentification, comptes de services bloqués, paquets perdus, impossibilité de faire une sauvegarde/restore, jobs qui refusent de se lancer, tickets de sessions plus courts...
Je continue ou... :

Pour le rendre "fonctionnel", il faut supprimer la sécurité du DC, donc ensuite c'est bien plus facile d'obtenir le compte admin de votre domaine et d'attaquer à partir de là le reste du domaine.

Merci

[dbaffaleuf]

Hello,

Idéalement, SQL Server doit se trouver sur une machine dédiée. Après, mutualiser pour des raisons de coûts, je pense que c'est un mauvais calcul, que ce soit avec IIS, un serveur d'appli, ou un contrôleur de domaine. Il y a des cas ou l'install ne pourra même pas se faire (en cluster, ou l'impossibilité de créer des comptes de groupes MSSQL dans l'AD si l'installation ne se fait pas avec le compte admin de domaine). Sans parler de la réponse du support le jour où un problème arrive.

De mon point de vue c'est niet. Le rôle de chaque serveur doit être cloisonné.

cf http://msdn.microsoft.com/en-us/libr...spx#DC_Support

David B.

[zinzineti]

Hello,
Idéalement, SQL Server doit se trouver sur une machine dédiée. Après, mutualiser pour des raisons de coûts, je pense que c'est un mauvais calcul, que ce soit avec IIS, un serveur d'appli, ou un contrôleur de domaine. Il y a des cas ou l'install ne pourra même pas se faire (en cluster, ou l'impossibilité de créer des comptes de groupes MSSQL dans l'AD si l'installation ne se fait pas avec le compte admin de domaine). Sans parler de la réponse du support le jour où un problème arrive.
De mon point de vue c'est niet. Le rôle de chaque serveur doit être cloisonné.
cf http://msdn.microsoft.com/en-us/libr...spx#DC_Support
David B.

Je suis d'accord avec David, mais j'ai l'impression que très souvent ceux qui décident du nombre de machines à acheter ne voient pas l'intérêt d'avoir un serveur dédié uniquement à SQL SERVER . Tout récemment j'ai insisté pour qu'on sépare le serveur d'appli IIS de la base de données SQL SERVER, mais en vain...
et celà j'imagine pour des raisons de coûts et surtout d'ignorance.
A votre avis à part les arguments de performances quels autres arguements peut-on utiliser pour attirer l'attention sur l'urgence d'avoir un serveur dédié pour SQ SERVER ?
Là où le bât blesse c'est que pour ORACLE le message passe bien. ce n'est pas difficile d'avoir un serveur dédié à ORACLE.
Et pourtant ils sont des SGBD ?
Que dois-je faire

[dbaffaleuf]

1) Pour ne pas avoir à brider les ressources. SQL Server comme Oracle, Sybase ou MySQL sont faits pour tirer le maximum des ressources qu'on leur expose (CPU, mémoire, HBA, disque...). S'ils doivent entrer en concurrence avec d'autres exécutables, il faudra jouer avec la priorité, l'affinité CPU, brider la mémoire, etc...
2) Parce qu'un serveur de fichiers ne se configure pas comme un serveur de bases de données.
3) Comment mesurer l'impact de passer un patch OS pour corriger un problème relatif à SQL Server (au niveau du framework .NET par exemple) sur les autres composants si la machine n'est pas dédiée ? ou l'inverse ?
4) Pour ne pas qu'une autre application ne compromette le niveau de service de la base: la disponibilité, les temps de réponse. Que se passe-t-il s'il faut redémarrer la machine parce qu'un process java ne libère pas sa mémoire et oblige windows à swapper ?

etc ...

David B.

[zinzineti]

Il faudra que j'apprenne par coeur ces arguments là
Il y a t-il d'autres arguments ?
histoire d'avoir une liste exhaustive du pourquoi faut-il avoir un serveur dédié SQL SERVER [j'insiste sur SQL SERVER parce qu'il y a pratiquement pas de refus quand on propose l'achat d'un serveur dédié ORACLE ]
Merci d'avance