Discussion :

[StringBuilder]

Bonjour,

Sur un serveur mutualisé de bases de données, nous avons actuellement une seule instance qui fait tourner une vingtaine de bases de données.

La version de SQL Server Express étant limité à 1 Go d'utilisation de mémoire par instance, le goulot d'étranglement se situe au niveau de la mémoire.

Dans un post antérieur, SQL Pro m'avais déconseillé de passer par de multiples instances, mais à l'époque, il s'agissait d'utiliser une version Web ou Standard, qui n'ont pas cette limitation d'utilisation de la RAM.

Du coup, la question revient sur le tapis : est-ce déconnant de créer par exemple 4 instances (sur un serveur qui a 8 Go de RAM) et répartir les bases de données sur ces 4 instances, ou de tout laisser dans la même instance ?

Le serveur a 8 coeurs.
Est-ce utile (indispensable ?) de séparer les instances par cœur ?

En effet, la multiplication d'instances semble être un gaspillage certains en termes de ressources (plusieurs occurrences du moteur en //) mais devrait tout de même permettre d'augmenter la quantité de mémoire disponible par base de données...

[Invité]

Personnellement, y a un moment, quand on veut être professionnel, on utilise les versions professionnelles.
C'est sûr que l'on peut faire des économies court terme mais par expérience, on dépense finalement plus à faire de la bidouille (et surtout la maintenir) que d'aller avec la solution la plus pertinente.

Désolé pour la non réponse.

Tu ne disposes que d'un seul serveur ? Est-ce qu'il est dédié au moins ? 8Go de Ram, c'est tout de même pas extraordinaire de nos jour...

[StringBuilder]

Et encore, t'as pas tout vu, y'a que 40 Go de disque...

En fait, il s'agit d'un serveur d'hébergement.
Il est planifié à moyen terme une montée en version (avec certainement un éclatement en plusieurs serveurs à long terme) mais là c'est que le début.
Et en attendant d'avoir des loyers pour payer les futures licences, faut faire avec les moyens du bord... Donc le serveur, c'est du surplus de l'armée de Dell, et les licences, c'est tout juste si l'admin à bien voulu installer un Windows Server...

Cependant, mise à part les quelques minutes d'installation d'une nouvelle instance, je vois pas en quoi :
- les scripts de maintenance ne seraient pas duplicables d'une instance à l'autre
- en quoi avoir plusieurs instances/serveur change quoi que ce soit en ce qui concerne les plans de maintenance/backup

[Invité]

Et encore, t'as pas tout vu, y'a que 40 Go de disque...

Ok, ben y reste plus qu'à raccorder des disques externes par USB...
Ok, j'ai vu ça à une époque de vache maigre chez mon employeur. Les performances sont... ébouriffantes !

[mikedavem]

Ok, ben y reste plus qu'à raccorder des disques externes par USB...
Ok, j'ai vu ça à une époque de vache maigre chez mon employeur. Les performances sont... ébouriffantes !

C'est la crise ...

++

[StringBuilder]

Et sinon, mise à part la dimension "allo t'es informaticien et t'as pas de sous ? nan mais allo quoi !", une réponse sérieuse ?

[mikedavem]

Pour être plus sérieux donc ..

Ce n'est pas forcément déconnant d'avoir plusieurs instances SQL Server installés sur un même serveur. Dans des projets de consolidations cela peut tout à fait arriver avec comme principale raison : le coût. A partir du moment où cela a été bien architecturé et dimensionné cela ne pose pas vraiment de problème. Cependant la consolidation des instances sur un même serveur implique également d'autres problématiques comme par exemple la criticité du nouveau serveur et donc la disponibilité à avoir en cas de crash de ce serveur ou de mise à jour.

++

[StringBuilder]

Ok.

Du coup je pense qu'on va partir là dessus pour les prochaines bases à installer.

Pour ce qui est de la criticité, nous avons déjà un serveur de secours qui contient une copie des bases h-6 qui est mis à jour automatiquement par tâche planifiée : toutes les 6 heures, l'ensemble des bases du serveur sont backupées puis restaurées sur le second serveur, capable de prendre la relève à chaque instant si le premier serveur est défaillant. Les deux serveurs ont autant de nom d'hôte dans le serveur DNS qu'il y a de base, donc comme ça, base par base, on est capable de switcher sur le serveur de secours en cas de besoin, de façon transparente.

C'est pas vraiment de la haute dispo, mais étant donné les besoins et la volumétrie, c'est un risque acceptable pour le moment.

On pourrait imaginer, pour maximiser les performances, croiser les deux serveurs (à savoir les bases A, B, C et D maîtres sur le serveur 1, et les bases E, F, G et H maîtres sur le serveur 2), mais ça risquerait de devenir source de confusion en cas de plan de secours : quand un serveur tombe, on est généralement tout sauf zen, donc je pense qu'il vaut mieux sacrifier quelques optimisations et rester simple

[Invité]

Juste pour clore le sujet, je suis aussi d'accord que ce système devrait probablement marché d'après les informations que tu donnes.
Mais si je suis un peu lourd, c'est que par mon expérience au sein d'une PME fauchée à une époque, plus tu arranges des trucs bancales pour économiser six francs six sous, plus on charge la mule jusqu'au point limite.
Perso, il y a des vieux bricolages qui nous coutent vraisemblablement une fortune et qui sont quasiment impossible à migrer vers une vraie solution professionnelle du fait que ce sont des bricolages avec tous les aléas qui vont avec.
En conlusion, c'est juste que les économies courts termes n'en sont pas à moyen termes.
Je comprends tout à fait que les fonds manques mais celui qui tient les cordons de la bourse doit en être conscient et c'est là où tu dois te transformer en Jedi pour obtenir ces fonds dans les budgets futures.


Et pour les disques externes en USB, chez nous, ils étaient branchés sur notre baie de disques et avaient des VM de moindre importance dessus, pour vrai !
Après ils ont acheté une autre baie d'occasion sur eBay justement...

[StringBuilder]

Je comprends tout à fait ton expérience et ce envers quoi tu cherches à me mettre en garde.

Mais dans mon cas, le périmètre reste très limité, et, à moins que je ne sois totalement à la rue au niveau administration SQL Server (ce qui est fort possible, je ne suis absolument pas DBA de formation), ce que je cherche à mettre en place ne nous prive pas d'une montée en version ultérieure et un retour vers une seule instance.

En effet :
- Sur ce serveur, nous hébergeons X fois la même base de données (base de données d'un logiciel éditeur). Donc les paramétrages et optimisations, dans les grandes lignes, seront vraies aussi bien pour une base que pour une autre, puisqu'elles ont la même structure et sont utilisées de la même manière.
- Nous sommes très limité en termes d'administration : en effet, le logiciel gère lui-même les tables des colonnes, et pour se faire, la moindre modification engendre une destruction puis re-création de la table, avec toutes les optimisations que nous aurions pu y apporter (index, colonnes calculées, etc.)

Par conséquent, actuellement la configuration se limite à pas grand chose, principalement un script de backup qui permet de faire la réplication sur le second serveur.
Même si demain nous évoluons vers une version Web ou même Standard, dans un premier temps, nous conserverons ce mode de réplication qui est de toute façon vendu tel quel aux clients.

Pour le moment, il y a 3 clients actifs sur le serveur. Pas du tout de quoi payer une version Standard... Au bout d'un an, à peine une version Web. Les clients étant amenés à venir "en masse", nous nous poserons rapidement la question de faire évoluer tout ça, et notre méthode de sauvegarde nous permet sans problème de monter un nouveau serveur en quelques minutes (le temps de remonter les backups) : donc même quand nous aurons plusieurs dizaines de bases réparties sur plusieurs instances, nous pourront parfaitement, en une soirée ou un weekend, basculer sur un nouveau serveur avec une version plus puissante.

D'après ce que j'ai compris, on peut même monter en version directement à partir de SQL Server Express (c'est tout du moins ce qui est écrit dans la page de téléchargement, on peut upgrader "seamlessly" vers n'improte quelle autre version).

Donc avec une coupure de moins d'une heure il est peut-être même possible de basculer en mono-instance d'une version Web ou Standard.

En tout cas, je te rejoint : mettre plusieurs instances de SQL Server Express sur un même serveur est la seule bidouille que j'accepterai de faire pour pallier aux manques de moyens.

C'est juste que là, on va potentiellement devoir installer plusieurs nouveaux clients dans un délai très court, qui nous oblige à préférer "continuer comme ça en évitant de trop dégrader les perfs" que de tout upgrader les yeux bandés, faute de temps pour avoir bien planifié.

Au pire, au lieu de monter plusieurs instance, on montera plusieurs serveurs. Mais vu que le serveur actuel est sous-exploité (1 instance SQL Server Express = 1 Go, ce qui est ridicule), je trouve ça dommage de monter un second serveur "pour rien".