![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>C’est par l\u00e0 qu’on commence… \u00e0 faire des b\u00eatises en g\u00e9n\u00e9ral. SQL Server, c’est facile, on clique, suivant, suivant et hop c’est fini.<\/p>\n
H\u00e9las, ce n’est pas plus facile qu’un autre SGBD. C’est juste plus facile de se tromper. Voici quelques r\u00e8gles de bases lorsqu’on s’appr\u00eate \u00e0 installer un SQL Server en production. Episode 1: le mat\u00e9riel.<\/p>\n
1) La machine: physique ou virtuelle ? <\/strong> 2) Admettons, machine physique: DEDIEE\/MUTUALISEE: <\/strong>en fonction des moyens. Mais id\u00e9alement il faut une machine d\u00e9di\u00e9e. Les petits budgets vont faire tourner IIS et SQL Server sur la m\u00eame machine, et d’exp\u00e9rience, c’est un mauvais calcul. Il vaut mieux investir un peu plus dans deux machines, et on aura moins de soucis ensuite. Il para\u00eet que je fais des articles trop longs, donc ce sera tout pour aujourd’hui \ud83d\ude09 A+ [ David B. ]<\/p>\n
\nLe gros d\u00e9bat des mois \u00e0 venir. M\u00eame si la plupart des clients vont conserver des machines physiques pour leurs bases critiques, il y aura des bases de prod, uat, dev, qualif moins critiques qui seront virtualis\u00e9es.
\nLes constructeurs (Dell, HP,…) sortent de plus en plus des chassis d\u00e9di\u00e9s \u00e0 la virtualisation, avec ESXi embarqu\u00e9. La virtualisation est (heureusement ? maheureusement ?) un train en marche, et plut\u00f4t que de freiner des quatre fers, posons-nous la question “comment virtualiser”, parce qu’il ne faut pas se voiler la face, on va y venir de toutes fa\u00e7ons, ce n’est qu’une question de temps. HYPER-V et ESX sont tous les deux de bons concurrents, et ESX est annonc\u00e9 compatible avec les produits MS. La combinaison des technos aujourd’hui (full virtualisation + assistance mat\u00e9rielle) fait que l’overhead de performances se r\u00e9duit de plus en plus (on est quasiment en CPU-direct sur les Intel-VT et les AMD-V). Je penche personnellement pour le raw device mapping, une assistance mat\u00e9rielle CPU et une configuration m\u00e9moire appropri\u00e9e. Dans quelques temps nous aurons un ESX ou deux et nous pourrons tester tout \u00e7a.<\/p>\n
\n<\/strong>LE PRIX ! <\/strong>Franchement les configurations \u00e0 moins de 8000\u20ac sont assez r\u00e9pandues et fiables. Je pense au HP Proliant DL 580 G5 (2×4 Xeon 3Ghz, 4Gb RAM, 2 cartes 1ge et 16 slots disque pour $7600) ou au tr\u00e8s populaire Dell PowerEdge 2950 III (m\u00eame config mais avec seulement 6 slots disques pour $3600).<\/p>\n
\n
\nCPU: <\/strong>le plus de cores il a sous le coude, et le mieux il se porte, SQL Server. Il est multithread\u00e9, il sait parrall\u00e9liser ses traitements. Evidemment il faut partir directement en 64 bits (EM64T, IA64, AMD64). Attention les \u00e9diteurs commencent \u00e0 revoir leur politique de licence par socket, ils perdaient trop d’argent avec les hexacores et certains commencent \u00e0 limiter \u00e0 6 cores par socket. Et attention \u00e0 ne pas activer l’hyperthreading sur les machines SQL Server.
\n
\nMEMOIRE: <\/strong>Oublier le 32 bits, la version 2008 de Windows Server sera la derni\u00e8re \u00e0 \u00eatre propos\u00e9e dans ce mode. En 64 bits, et avec le prix de la DDR2, il ne faut pas l\u00e9siner. C’est encore plus important que la CPU. Plus le cache de donn\u00e9es est gros, moins SQL Server fera de lectures physiques.
\n
\nRESEAU<\/strong>: Ca d\u00e9pend. Je suis intervenu chez un client DRM il y a quelques temps et l\u00e0 le r\u00e9seau c’\u00e9tait VRAIMENT crucial. Ca va le devenir de plus en plus avec FILESTREAM, la spatialisation, la vid\u00e9o HD, le plus de donn\u00e9es on stocke, et le plus de donn\u00e9es on va faire transiter. Les cartes et les core switches en 10Ge sont l\u00e0, les Jumbo Frames, donc tout \u00e7a suit derri\u00e8re. Le r\u00e9seau entre syst\u00e8mes Production \/ Secours est aussi crucial (Database mirroring, r\u00e9plication). Nous avons un client en database mirroring 2005 qui avait install\u00e9 un lien 100Mb entre ses deux sites, il va passer en fibre car il a de plus en plus de choses \u00e0 faire passer sur le lien en plus du streaming li\u00e9 au DB mirroring (sauvegardes, recopies de fichiers, etc…). Autre exemple, un client qui a une r\u00e9plication transactionnelle entre Frankfort et Londres, le lien est vraiment tr\u00e8s lent, et la resynchro de r\u00e9pli (34Gb) se fait en moyenne en 10-12 heures.
\nMais si l’application est cod\u00e9e en proc\u00e9dures stock\u00e9es, que la quantit\u00e9 de donn\u00e9es qui transite n’est pas importante et que SQL server est standalone, alors une carte 100Mb\/s devrait faire l’affaire.
\n
\nDISQUES: <\/strong>tout le monde ne peut pas se payer un SAN, je pense aux petites PME du web avec 1 machine serveur, un IIS et une base de donn\u00e9es de production, avec des moyens modestes. Donc on va consid\u00e9rer deux configurations: les disques internes pour les petits, et le stockage en r\u00e9seau pour les riches et la classe moyenne.
\n – DISQUES INTERNES<\/strong>:<\/em> choisir du SAS en 15KRPM. Le disque pour la base de donn\u00e9es, c’est le nerf de la guerre. Le HP DL580 G5 avec ses 16 slots est parfait, il permet de faire trois RAID10 (data, log, backup) et un RAID1 (syst\u00e8me) et de garder deux slots de spare. Il faudra v\u00e9rifier au niveau de l’interface du contr\u00f4leur SAS que celui-ci est bien sur batterie et que celle-ci est valide, et que la politique est en write-through, c’est \u00e0 dire que le cache du contr\u00f4leur n’est pas utilis\u00e9 en \u00e9criture. Les disques SAS 73 Gb 15KRPM sont \u00e0 330\u20ac chez Dell en 2’5, \u00e7a ne vaut pas le coup de se priver.
\n– STOCKAGE RESEAU<\/em>: <\/strong>ne pas utiliser de NAS au sens strict (attachement r\u00e9seau), pas de CIFS, ce n’est pas support\u00e9 de base par SQL Server. Il faut que les disques soient vus comme des disques locaux, donc soit une baie avec un attachement direct, soit un SAN. Pour les riches, le SAN en fibre channel est \u00e0 privil\u00e9gier. Pour la classe moyenne, le iSCSI est un bon moyen de faire du SAN \u00e0 moindre co\u00fbt, \u00e0 la condition d’utiliser sur la machine h\u00f4te un initiateur mat\u00e9riel et non logiciel, c’est \u00e0 dire une carte 1Ge qui soit compatible TSO (TCP Segmentation Offload, calcul de la pile TCP d\u00e9charg\u00e9e du CPU h\u00f4te), et que le r\u00e9seau soit d\u00e9di\u00e9 au stockage. Pour les disques SAN, m\u00eame politique que les disques internes. Au niveau du choix de la baie, il faut regarder plusieurs choses: Le nombre de storage processors (va d\u00e9terminer le multiplexage des entr\u00e9es, il en faut au moins 2), la taille du cache par storage processor et non en globalit\u00e9, le nombre de slots pour les disques, la capacit\u00e9 globale. Le plus important c’est la taille du cache par SP. Si les caches entre SP sont mirror\u00e9s l’un sur l’autre, on perd la moiti\u00e9 de la capacit\u00e9 m\u00e9moire, si la baie est mirorr\u00e9e sur une autre, on perd encore car le soft de miroir utilise des buffers dans le cache de chaque SP. Ensuite, il faut voir comment le cache est partitionn\u00e9 entre les lectures et les \u00e9critures. Le plus souvent, c’est fait \u00e0 la louche pour des syst\u00e8mes majoritairement en lecture, mais attention \u00e0 ne pas n\u00e9gliger les \u00e9critures en transactionnel. Un cache en \u00e9criture plein, et les queues se remplissent au niveau des SP, on observe des outstanding IOs c\u00f4t\u00e9 SQL Server et c’est rapidement la cata.<\/p>\n
\nProchain \u00e9pisode, l’installation Windows et les pr\u00e9requis SQL Server.<\/p>\n