Discussion :

[StringBuilder]

Bonjour,

Je vais devoir installer SQL Server 2008 R2 en mode "cloud".
Sorti de l'aspect commercial, ça devrait se traduire au final par un simple serveur mutualisé, qui va faire tourner X instances d'une même base de données, de façon la plus cloisonnée possible.

Je pense que ce sera une version Entreprise qui sera installée, à moins qu'un Professional soit suffisante, je dois étudier les capacités et limitation des différentes éditions.

Comme piste préliminaire, j'ai pour idée de créer autant d'instances nommées que de clients.
Ceci ayant plusieurs avantages :
- cloisonnement "complet" des ressources physiques et logiques
- capacité plus aisée pour basculer par la suite sur plusieurs machines physiques distinctes

En revanche, en termes de ressources machine, n'est-pas pas plus lourd que de gérer plusieurs bases distinctes sur une même instance ? Chaque client aura à chaque fois plusieurs bases (au moins deux). Quelles autres solutions pour séparer facilement les bases d'un client de celles des autres, sans pour autant devoir modifier autre-chose que la méthode de connexion à ces dernières ? (donc pas de schema par exemple, je ne maîtrise pas les requêtes qui sont jouées, donc il est possible que "dbo" soit par exemple en dur).

Quelles autres indications/contre-indications ?

Et surtout, comment ça se passe pour créer plusieurs instances nommées en termes de licences et d'installation/administration ?

J'avoue que je me retrouve "expert" alors que je ne connais que les versions Express, du coup je suis un peu perdu...

[Kropernic]

Hello,

Je suis encore loin d'être un expert mais voilà ma petite pierre à ton édifice.

Entre plusieurs instances/une DB et une instance/plusieurs DB, je pense que la 2e solution sera plus facile à gérer.

Si mes souvenirs sont bons, lorsque plusieurs instances cohabitent sur un même serveur physique, il faut alors définir la part de RAM que chacune d'elles a le droit d'utiliser. Autrement, elles vont se gêner l'une l'autre.
S'il n'y a qu'une seule instance, il n'a bien sûr pas se problème de gestion de RAM. Mais par contre, si tu as un client qui fait systématiquement des requêtes pour lesquelles des volumes de données importants sont rapatriés, ce client va pénaliser les autres clients pour qui SQL SERVER devra aller rechercher les informations sur le disque alors qu'elles auraient pu se trouver en RAM.

Il y a donc à manger et à boire dans les deux solutions. Tout dépend du type de client que tu auras. Si c'est pour héberger de petites DB's, j'opterais pour la solution avec une seule instance. Si c'est pour héberger des DB's plus importantes, j'opterais pour la solution avec plusieurs instances avec répercussion de la RAM mise à disposition dans le prix de l'hébergement.

En espérant avoir aidé ne fut-ce qu'un peu.

[StringBuilder]

En fait, c'est pour héberger une application de type CRM.

Donc c'est des bases assez peu volumineuses (par rapport aux capacités d'un serveur actuel), par contre, potentiellement on pourra avoir plusieurs dizaines de bases.

Le fait de devoir spécifier la quantité de RAM utilisable pour chaque instance ne me gêne pas, si c'est une limite haute.

Genre sur un serveur avec 8 Go de RAM, autoriser 8 instances capable d'occuper chacune jusqu'à 2 Go.

En effet, sur un serveur mutualisé, cela ne me choque pas de brider les utilisateur et éviter que les 10% plus gourmands occupent 90% des ressources, et pénalisent ainsi les autres.

En revanche, je ne veut pas que cela se solde par une répartition (linéaire ou non) des ressources du serveur entre les clients, et qu'ainsi 90% des capacité du serveur soient gaspillées par les clients les moins gourmands.

Bon, après avoir indiqué que j'étais loin d'être un expert à mon chef, il devrait faire appel à un DBA externe pour installer et paramétrer le serveur (et déjà, simplement déterminer de quels sont nos réels besoins et ce que nous permet l'outil qui sera hébergé).

Si j'arrive à en savoir plus sur ce qui sera fait, je viendrai certainement dire ce qu'il en est ici

[darkelend]

Tu peux aussi faire une VM par client. Ce sera encore plus pratique à migrer dans le futur.
Moi comme ca, je partirai sur une instance par client, mais bon je n'ai pas toutes les cartes en main pour décider.

[StringBuilder]

C'est vrai que la VM par client est une solution aussi.
Mais c'est justement pour arrêter de démultiplier les VM que les admins veulent mettre en place un serveur mutualisé.
Cependant, en termes de licences, c'est pas une mauvaise idée, dans la mesure ou l'outil fonctionne parfaitement avec SQL Server Express...

[StringBuilder]

Finalement, en attendant d'avoir suffisamment de clients pour justifier l'utilisation de licences prohibitives de SQL Server Standard ou Entreprise, nous procédons comme suit :

Sur un même serveur, nous avons mis plusieurs instances de SQL Server Express.
Chaque instance fait tourner les bases de plusieurs clients.

Pour le moment ça tient la route (forcément, avec 1 seul client et deux bases à usage interne, ça va pas chercher loin )

J'ai une question à propos des tarifs de SQL Server.

L'application que nous déployons est une application WEB.

L'application se connecte à ses deux bases avec un seul utilisateur SQL Server (un user par client).

Mais en interne, l'application gère ses propres utilisateurs. Potentiellement, on peut avoir plusieurs dizaines ou centaines d'utilisateurs par client.

Si j'ai mettons :
- 500 utilisateurs de l'application Web
- répartis en 5 applications Web (et donc 10 bases, 5 utilisateurs SQL Server)
- Le tout serait hébergé sur un SQL Server Standard Edition
- Sur un serveur avec mettons 4 CPU quad cores

De quelles licences avons-nous besoin ?

Est-ce que les offres qu'on trouve sur Amazon autour de 2000 euros pour "1 server or 10 CAL" suffisent ? (j'ai bien un seul serveur, et moins de 10 utilisateurs nommés)
Ou si on doit acheter 500 licences, une pour chaque utilisateur de l'application ?
Ou acheter 16 licences "core" en mode leasing à plus de 10 000 euros par mois le core ?

(les deux dernières solutions sont ce que nous propose notre vendeur de licences en mode SAS... mais je trouve ça extrêmement bizarre, le prix de SQL Server à lui seul serait alors bien plus important que celui des licences pour le programme final, ce qui me semble délirant)

Qu'en pensez-vous ?