Discussion :

[FMJ]

Bonjour,

Je suis en train de lancer un AO pour le renouvellement de notre infra serveur de données, ce qui est fort attendu compte tenu de l'age néandertalien de notre serveur actuel (SQL Server 2000 sous Windows 2003 ... mais ça tourne toujours !)
Pour différentes raisons (dont financières, ce qui n'est pas négligeable pour une petite PME) ce SQL Server sera hébergé sur le nouveau contrôleur de domaine. Celui-ci est TRES peu sollicité, donc si ça tourne actuellement bien sur une version préhistorique, il ne devrait pas y avoir de souci sur un hardware beaucoup performant.
Ce sera la première question : voyez-vous des inconvénients majeurs à cette mutualisation ?

La seconde, c'est que le serveur sera virtualisé, notamment pour mettre en place une solution de PRA sur un autre serveur. Voyez-vous également des inconvénients à faire tourner une base de données en environnement virtualisé ?

Troisième question : Notre DB est un peu particulière. Peut-être que certains se rappelleront de cette fameuse base dont j'avais déjà parlé, avec sa table principale de 250 colonnes qui contient des millions de lignes.... Là-dessus je ne peux rien faire. Autant dire que la taille de la base égale quasiment celle de sa table principale. La base grandit de 8-10Go par an ... ce qui correspond à peu près à sa taille globale puisque j'ai mis en place une sauvegarde avec purge annuelle des données afin de préserver les performances (nous étions TRRRRES limités en RAM à cause de l'OS). Les requêtes lourdes nécessitent de charger toute la table principale, donc quasiment la taille de la base. Je finirais en indiquant que les ldf et la tempDB sont sollicités au ras des pâquerettes.
Donc ma question : Pensez-vous qu'il y ait un intérêt à créer un RAID 1 de SSD pour le système et la base de données, ce qui permettrait de booster énormément la "pagination", notamment quand on requête des bases sauvegardées ou bien des bases de test, ou bien est-il plus pertinent d'investir en blindant la RAM (je pensais à 64Go) ?
En terme de coût, je pense que les deux solutions ne seront pas très éloignées, sachant que vu la faible volumétrie d'échange annuelle et la priorité à la lecture, pas besoin de SSD avec des IOPS de F1 et une méga résistance à l'usure.

Merci pour vos lumières.

(je reenvoie aussi à cette discussion traitant du sujet : http://www.developpez.net/forums/d15...se-production/)

[StringBuilder]

En règle générale :
- Un serveur de base de données doit être un serveur dédié (performances / disponibilité du service)
- Un contrôleur de domaine doit être un serveur dédié (sécurité / disponibilité du service)
- Un serveur de base de données ne doit pas être virtualisé (performances / gestion de la concurrence des ressources)

Par conséquent, je ne pense pas que vous alliez dans la bonne direction.

Actuellement, votre contrôleur de domaine est sur un serveur qui arrive à faire tourner Windows 2003 + SQL Server.
=> Si demain il n'y a plus que Windows 2012 dessus, alors il devrait toujours très bien s'en sortir pour jouer son rôle de contrôleur de domaine

Ceci vous reste donc 100% de votre budget (au détail près de la licence Windows 2012) pour acheter un nouveau serveur physique dédié à SQL Server

Ensuite, le choix entre RAM et RAID 1 sera principalement déterminé par l'intensité de la charge du serveur, et le volume des données traitées durant cette charge.

En effet, si vous avez toute les minutes une requête qui scanne 100% de la taille de la base, alors tant que RAM < taille de la base, l'utilisation de cette dernière ne sera pas suffisante pour résoudre votre problème de performances.

En revanche, je vois que votre base fait autour de 10 Go.

Quel est l'intérêt d'avoir 64 Go de RAM à ce moment ?
=> SQL Server va certainement n'utiliser que 10% de la mémoire au final... sauf si vous vous lancez dans des produits cartésiens de votre table de 8 Go...

Donc je partirais sur un mix des deux : 32 Go devraient faire l'affaire, ce qui vous laisse de quoi acheter une dizaine de SSD dont vous monterez un certain nombre en RAID 1 (pour les DATA) et d'autres que vous dédierez à des fichiers qui nécessitent de bons temps de répons (LOGS par exemple).

PS : La taille de votre base étant petit, n'hésitez pas à acheter des petits disques SSD : les gros ne sont pas forcément plus rapides, et sont beaucoup plus chers. Mieux vaut avoir beaucoup de petits disques que 2 ou 3 gros que vous partitionnerez ensuite...

[FMJ]

Bonjour et merci pour ta réponse.

Concernant le contrôleur AD je serais assez d'accord avec toi mais il faut également tenir compte des points suivants :
> Le serveur actuel a 10 ans. Les disques sont récents, l'alim est redondée mais pas le contrôleur RAID. Le jour où ce dernier lâche, je serais un peu embêté... La gestion du directory n'est pas stratégique pour la boîte, par contre le fonctionnement du serveur de fichiers beaucoup plus !
> L'achat d'une licence serveur + ses CAL hors OEM est loin d'être anecdotique. Il est même très supérieur à l'acquisition d'un nouveau serveur light.
> Il y a très peu d'activité au niveau de l'AD et du serveur de fichiers. Le serveur d'impression ne serait même pas utilisé. Pour moi son impact serait très peu signifiant au niveau CPU, mémoire et accès disque.
> La mutualisation de l'AD et de la DB est à la fois plus simple en gestion, plus facile pour mettre en oeuvre un PRA avec une machine mirrorée qui sauvegarde la totalité des services de la société, et enfin une optimisation financière non négligeable.


Concernant l'hébergement par un hyperviseur, quels sont les facteurs pénalisants ?

Ensuite pourquoi 64Go de RAM ? C'est effectivement un peu riche, je pensais initialement à 32Go. Pour 3 raisons :
> La base ne fait que 10Go la première année mais si je laisse tomber sa purge saisonnière, elle fera 20Go l'année suivante, 30Go la 3eme et ainsi de suite.
> Il faut en laisser un peu pour l'hyperviseur et l'OS.
> De même pour les bases de test.
> Pour finir, il est plus facile de faire passer ce genre de budget en mode projet qu'en ajout saisonnier. C'est pas logique mais c'est comme cela !

Quand tu parles d'une dizaine de SSD équivalent à 32Go de RAM en budget, tu penses à quoi comme SSD ? Parce que 2 barrettes DDR4 de 16Go EEC, c'est de l'ordre de 300-350€. Et un SSD grand pulic Pro de 300Go, c'est du même ordre.
Il y a un intérêt à séparer Data et logs sur une grappe de SSD ? mais effectivement un RAID n'a pas grande utilité pour les logs, il suffit d'avoir un SSD de spare.

Au fait en SSD, pour un besoin en terme de perf somme toute très limiter, du SATA suffit ? Ou il faut quand même taper dans du SAS, voire du PCIe (ouille la note !) ?
Je ne serais pas étonné qu'un SSD Pro en SATA éclate un disque dur 15000trpm autant en débit, latence et IOPS !

[SQLpro]

Concernant l'hébergement par un hyperviseur, quels sont les facteurs pénalisants ?

Extrait de mon livre :
"
13.2.2 - Machine virtuelle

Comme nous l’avons mentionné au paragraphe 13.1.3 (SQL Operating System - SOS), les couches supplémentaires apportées par la virtualisation (VMWare, Hyper V...) ne font qu’apporter du bruit, donc une perte naturelle de performances (au mieux 2% de pertes mais souvent beaucoup plus, de l’ordre de 8 à 15 % !)... Mais ce n’est pas tout :
• Microsoft n’offre aucune garantie que SQL Server fonctionne correctement dans un système virtualisé (y compris sur Hyper V) et recommande de reproduire les dysfonctionnements sur une machine physique en cas d’appel à la hot line ;
• un grand nombre de compteurs de performances n’offre plus de données fiables (toutes les métriques incorporant le temps, prennent en compte le temps réel ce qui inclut les temps de gestion de la VM, et les temps d’utilisation des autres machines, si plusieurs VM figurent sur la même machine...) ;
• le diagnostic des problèmes de performance devient très difficile à établir car il n’est pas facile de savoir sur quelle couche investiguer et comment ses différentes couches interagissent ;
• la sauvegarde des VM n’est pas fiable pour les bases SQL Server, du fait des opérations d’écriture asynchrones et non sérialisées, sauf à utiliser un outil supplémentaire (VSS par exemple) qui « gèle » les bases le temps de procéder à la copie des fichiers, ce qui rend indisponible la pleine utilisation des bases le temps de procéder au snapshot de la VM ;
• le coût de licence entre l’OS, la VM et SQL Server devient supérieur à celui d’une machine physique sans VM lorsque la solution porte sur des volumétries importantes (plus de 100 utilisateurs, plus de 300 Go de bases de données, plus de 8 CPU, plus de 64 Go de RAM...).
"

Mais il y a beaucoup d'autres considération à lire pour cela... environ 7 à 8 pages dans le livre !

Ensuite pourquoi 64Go de RAM ? C'est effectivement un peu riche, je pensais initialement à 32Go. Pour 3 raisons :
> La base ne fait que 10Go la première année mais si je laisse tomber sa purge saisonnière, elle fera 20Go l'année suivante, 30Go la 3eme et ainsi de suite.
> Il faut en laisser un peu pour l'hyperviseur et l'OS.
> De même pour les bases de test.
> Pour finir, il est plus facile de faire passer ce genre de budget en mode projet qu'en ajout saisonnier. C'est pas logique mais c'est comme cela !

Quand tu parles d'une dizaine de SSD équivalent à 32Go de RAM en budget, tu penses à quoi comme SSD ? Parce que 2 barrettes DDR4 de 16Go EEC, c'est de l'ordre de 300-350€. Et un SSD grand pulic Pro de 300Go, c'est du même ordre.

Un SSD de serveur n'est pas un SSD de portable. Et pour les SSD de serveur il en existe de 3 catégories :

• les read intensive => inutile pour les BD qui font du cache
• les write intensive => spécialement conçus pour les BD
• les carte PCI SSD => le top du top.

A lire : https://www.hpe.com/h20195/v2/GetPDF...A4-7186ENW.pdf
Un SSD de portable à 500 € ne tiendra pas plus de quelques mois :
Pour SSD de serveur write intensive ou PCI de 1 To comptez entre 2 000 € et 8 000...

Il y a un intérêt à séparer Data et logs sur une grappe de SSD ? mais effectivement un RAID n'a pas grande utilité pour les logs, il suffit d'avoir un SSD de spare.

Lisez le chpitre stockage de notre livre (70 pages). Les JT sont écrits de manière synchone en WAL et les data de manière asynchrone en RANDOM. Donc oui !

Au fait en SSD, pour un besoin en terme de perf somme toute très limiter, du SATA suffit ? Ou il faut quand même taper dans du SAS, voire du PCIe (ouille la note !) ?
Je ne serais pas étonné qu'un SSD Pro en SATA éclate un disque dur 15000trpm autant en débit, latence et IOPS !

A +

[FMJ]

Bonjour Frédéric et merci pour cette réponse.

Je suis d'accord avec toi ... dans un environnement professionnel d'une certaine taille. En ce qui nous concerne, nous sommes une tout petite PME et la sollicitation du SQ Serveur est très très limitée :
> 7 mois sur 12, il y a 5 personnes connectées à la base (pas en simultané), avec quelques Mo de données échangées par jour. Très faible activité.
> Au plus fort de l'activité, i.e. les deux mois estivaux, il y a jusqu'à 20 personnes connectées (mais peut-être 2-3 personnes peuvent requêter en simultané). J'estime à 100Mo grand max le volume échangé
> 99% de ces transactions concernent des lectures/écritures très ciblées. Il n'y a que trois personnes qui peuvent être amenées à faire du requêtage décisionnel qui brasse la quasi totalité de la base. Mais c'est très ponctuel.
L'objet de mes interrogations vise une optimisation de ce requêtage décisionnel + de certains indicateurs qui doivent être calculés souvent sur la totalité des pièces parce que l'ERP ne les agrège pas par défaut dans une table de stats comme d'autres indicateurs. (exemple très con : quand une réception, une vente, un transfert, etc., est réalisé pour un article donné, un indicateur correspondant est mis à jour dans un table de statistiques. Donc quand on souhaite connaître la stat de vente d'un article à un instant t, on consulte juste cette table, pas la peine de parcourir toutes les pièces vente. Mais pour les commandes, c'est indicateur n'existe pas dans la table des stats....)
Bref, si l'ERP était mieux pensé et la base mieux structurée, je ne me poserais pas toutes ces questions de perf.

Pour finir je suis d'accord qu'un SSD grand public va vite saturer s'il est utilisé pour du DB très sollicitée d'une grosse PME.
Pour autant, si tu prends par exemple un Samsung 960 Pro 512Go en M.2, il est tout de même donné avec :
> débit séquestiel 4K : wrtite 3.5Go/s / read 2.1Go/s
> 360 000 IOPS max en écriture/lecture (avec une queue de 16, il est plutôt à 100 000IOPS ce qui est déjà énorme !) :
> Une durée de vie de 400To, 1.2Po pour le 1To !......
http://www.storagereview.com/samsung...vme_ssd_review
Dans notre cas, je crois que l'on pourrait envisager sereinement la demi-vie !
Et peut-être mieux que les dernier Savvio 15K que j'ai montés l'an dernier, et qui n'ont pas fait un an les DEUX ! , pour seulement une poignée de Go transférés. Un honte !
Donc pour le même prix, je me tâte bien de prendre ce type de SSD PCIe ?! On parle d'un SSD à moins de 300€HT, soit à peu près le coût du SAVVIO susmentionné.
Reste la question de trouver des contrôleur RAID qui supporte ce type de port ?! et qui soit bien compatible avec la plateforme hardware ....
De toute façon, je peux toujours essayer, quitte à revenir sur des HD traditionnels si je veux que ça coince dans les benchs.

Toujours est-il que c'est effectivement l'occasion de prendre ton livre que je zieute depuis un moment.

Merci !

[FMJ]

Ayez ! Commandé pour une lecture au pied du sapin !

[SQLpro]

Bonjour,

Je suis en train de lancer un AO pour le renouvellement de notre infra serveur de données, ce qui est fort attendu compte tenu de l'age néandertalien de notre serveur actuel (SQL Server 2000 sous Windows 2003 ... mais ça tourne toujours !)
Pour différentes raisons (dont financières, ce qui n'est pas négligeable pour une petite PME) ce SQL Server sera hébergé sur le nouveau contrôleur de domaine. Celui-ci est TRES peu sollicité, donc si ça tourne actuellement bien sur une version préhistorique, il ne devrait pas y avoir de souci sur un hardware beaucoup performant.
Ce sera la première question : voyez-vous des inconvénients majeurs à cette mutualisation ?

Comme déjà dit, oui pour des raions de performances et de sécurité

La seconde, c'est que le serveur sera virtualisé, notamment pour mettre en place une solution de PRA sur un autre serveur. Voyez-vous également des inconvénients à faire tourner une base de données en environnement virtualisé ?

Le but primale de la virtualisation n'est pas de faire un PRA et encore moins un PCA... C'est d'économiser sur les ressources, les licences ! La virtualisation des serveurs SQL posent plus de problème qu'elle n'en résout. Lisez le livre que nous avons écrit pour vous en convaincre... Toutefois si vous persistez dans cette voie préférez Hyper V plus stable avec SQL Server

Le mieux serait : un gros serveur pour SQL, un petit serveur pour votre AD

Troisième question : Notre DB est un peu particulière. Peut-être que certains se rappelleront de cette fameuse base dont j'avais déjà parlé, avec sa table principale de 250 colonnes qui contient des millions de lignes.... Là-dessus je ne peux rien faire. Autant dire que la taille de la base égale quasiment celle de sa table principale. La base grandit de 8-10Go par an ... ce qui correspond à peu près à sa taille globale puisque j'ai mis en place une sauvegarde avec purge annuelle des données afin de préserver les performances (nous étions TRRRRES limités en RAM à cause de l'OS). Les requêtes lourdes nécessitent de charger toute la table principale, donc quasiment la taille de la base. Je finirais en indiquant que les ldf et la tempDB sont sollicités au ras des pâquerettes.
Donc ma question : Pensez-vous qu'il y ait un intérêt à créer un RAID 1 de SSD pour le système et la base de données, ce qui permettrait de booster énormément la "pagination", notamment quand on requête des bases sauvegardées ou bien des bases de test, ou bien est-il plus pertinent d'investir en blindant la RAM (je pensais à 64Go) ?

Préférez 128 Go de RAM et des disques magnétiques en RAID 10. Pourquoi 128 Go, parce que avec une seule grosse table vous allez fortement solliciter la tempdb pour chaque GROUP BY et ORDER BY et cela pour chaque utilisateur !

En terme de coût, je pense que les deux solutions ne seront pas très éloignées, sachant que vu la faible volumétrie d'échange annuelle et la priorité à la lecture, pas besoin de SSD avec des IOPS de F1 et une méga résistance à l'usure.

Merci pour vos lumières.

(je reenvoie aussi à cette discussion traitant du sujet : http://www.developpez.net/forums/d15...se-production/)

A +