Discussion :

[CUCARACHA]

Salut,

Je dois mettre en oeuvre un serveur SQL totalement redondé et je ne l'ai jamais fait.

J'aimerais savoir si la réplication et le clustering veulent dire la même chose ?

Si je veux monter un cluster de deux serveurs, dois-je doubler le nombre de licences ou la version entreprise permet-elle le clustering sans surcoût ?

Faut-il une version entreprise de Windows Server pour y déployer une version entreprise de SQL Server ?

D'avance merci

Laurent

[SQLpro]

J'aimerais savoir si la réplication et le clustering veulent dire la même chose ?

Pas du tout !

1) la réplication est une réponse fonctionnelle à un problème de répartition ou de centralisation des données. On répliques des informations, non des bases... Cela n'aurait aucun sens.

2) le clusterisation n'est pas la seule solution de haute dispo. C'est la plus complexe et le plus couteuse en matériel (approuvé) comme en admin.
Il existe aussi le log shipping et le mirroring. Si vous cherchez une solution synchrone, alors le mirroring est largement préfarable.

A lire : http://sqlpro.developpez.com/cours/s...disponibilite/

Si je veux monter un cluster de deux serveurs, dois-je doubler le nombre de licences ou la version entreprise permet-elle le clustering sans surcoût ?

Aucune licence n'est à payer (OS ou SQL) sur les serveurs froids.

Faut-il une version entreprise de Windows Server pour y déployer une version entreprise de SQL Server ?

La question est complexe car cela dépend à la fois des limites de CPU et RAM qui ne sont pas les mêmes dans les différentes version de Windows (2003, 2008 et 2008 R2) et dans SQL (2005, 2008, 2008 R2) !!!

Si tu nous en dit un peu plus.... on pourra mieux te conseiller !

A +

[CUCARACHA]

Salut,

merci pour ces réponses détaillées.

Toutes les machines seront sous Windows 2008 R2 mais nous n'avons pas encore déterminé les types Web, Std, Ets.

Toutes les bases seront sous SQL Server 2008 R2 certaines en Express, d'autres en Std ou Ets en fonction du besoin

Le besoin est que l'ensemble du système soit entièrement redondé pour pouvoir basculer tout seul en mode secours au cas où.

Nous avons actuellement un SLA de 99.5 et je veux que nous puissions faire du 99.9

Tous vos conseils et suggestions seront les bienvenus.

En termes de puissance il n'y aura un un trafic très intense sur les bases par contre il y aura un énorme trafic en termes de transferts de fichiers puisqu'il s'agit de transcodage vidéo hd donc on est sur du fichier de plusieurs giga et on en traite près d'une centaine à la fois et on en traite plusieurs milliers par semaine.

Le tout sera piloté et supervisé par 2 serveurs K2 eux mêmes redondés. Les formulaires seront dans deux serveurs web indépendants load balancés.

1 des serveur K2 gère la tolérence de panne et l'autre la prod. Le K2 de prod sera connecté au cluster SQL Server et, comme il a un mirroir, il faudra que ce dernier aussi.

K2 génère plusieurs bases (un peu plus d'une dizaine et nous aurons 1 base de données pour notre SI).

Etant donné qu'on a pas un besoin transcendantal de patate sur le serveur SQL je pensais mettre un Quad Core avec 8 Go de RAM (pour le début, la base ne devrait pas dépasser le giga avant au moins un an)

Toutes les autres machines seront dans deux fermes de virtualisation sur des sites distincts.

Pour les fermes je pensais mettre deux bécanes l'une sera assez puissante :
Au départ 16 cœurs avec 64Go RAM pour la plus grosse et la seconde (de secours) sera un bi xeon quad core soit 8 cœurs en tout avec la même quantité de RAM.
Coté disque on a besoin de 64 Tera pour le proxy (car les fichiers sont conservés quelques jours voir quelques semaines). Le serveur SQL aura ses propres disques locaux puisque la base est toute petite (en comparaison du reste de l’installation).
C’est assez détaillé là ?
°0°
++
Laurent

[SQLpro]

Salut,

merci pour ces réponses détaillées.

Toutes les machines seront sous Windows 2008 R2 mais nous n'avons pas encore déterminé les types Web, Std, Ets.

Exite le web qui ne permet pas grand chose...

Toutes les bases seront sous SQL Server 2008 R2 certaines en Express, d'autres en Std ou Ets en fonction du besoin

Exit express si vous voulez faire du mirroring...
Pourquoi avoir autant d'instances ? Ne pouvez vous pas mutualiser ??? Avez vous 1 serveur par instance ou sont-elles toutes hébergées sur le même serveur ?

Le besoin est que l'ensemble du système soit entièrement redondé pour pouvoir basculer tout seul en mode secours au cas où.

Nous avons actuellement un SLA de 99.5 et je veux que nous puissions faire du 99.9

On peut monter jusqu'à du 99.999% ce que j'ai fait pour plusieurs clients...

Tous vos conseils et suggestions seront les bienvenus.

En termes de puissance il n'y aura un un trafic très intense sur les bases par contre il y aura un énorme trafic en termes de transferts de fichiers puisqu'il s'agit de transcodage vidéo hd donc on est sur du fichier de plusieurs giga et on en traite près d'une centaine à la fois et on en traite plusieurs milliers par semaine.

Là il faut envisager de découpler physiquement les réseaux en ayant 2 cartes par serveur... D'un côté le trafic ordinaire, de l'autre la vidéo, surtout si vous êtes en streaming ! Sinon vous risquez d'avoir des temps d'attente erratiques du fait de la bande passante dans les tuyaux !

Le tout sera piloté et supervisé par 2 serveurs K2 eux mêmes redondés. Les formulaires seront dans deux serveurs web indépendants load balancés.

1 des serveur K2 gère la tolérence de panne et l'autre la prod. Le K2 de prod sera connecté au cluster SQL Server et, comme il a un mirroir, il faudra que ce dernier aussi.

K2 génère plusieurs bases (un peu plus d'une dizaine et nous aurons 1 base de données pour notre SI).

Attention à la solution de clusterisation : elle contient un SPOF qui est la baie de disque il faut donc la dupliquer par un système de "shadowing"

Etant donné qu'on a pas un besoin transcendantal de patate sur le serveur SQL je pensais mettre un Quad Core avec 8 Go de RAM (pour le début, la base ne devrait pas dépasser le giga avant au moins un an)

Voir moins, tout dépend du volume transactionnel. Préférez toujours mettre l'accent sur les disques et la RAM mais pas sur les processeurs, prenez une génération n-1 et pas une vitesse maxi !

Toutes les autres machines seront dans deux fermes de virtualisation sur des sites distincts.

Tous sauf les serveur SQL n'est-ce pas ?

Pour les fermes je pensais mettre deux bécanes l'une sera assez puissante :
Au départ 16 cœurs avec 64Go RAM pour la plus grosse et la seconde (de secours) sera un bi xeon quad core soit 8 cœurs en tout avec la même quantité de RAM.

Si tu fais du cluster il faut que les machines SQL soient STRICTEMENT IDENTIQUE et sur du matériel approuvé. Game particulière de serveur spécialement conçu pour SQL Server, exemple HP Serveur ProLiant ML350 G6

Coté disque on a besoin de 64 Tera pour le proxy (car les fichiers sont conservés quelques jours voir quelques semaines). Le serveur SQL aura ses propres disques locaux puisque la base est toute petite (en comparaison du reste de l’installation).

C’est assez détaillé là ?

Non... Pour ne pas se planter il faudrait faire une étude détaillée. Franchement tu risque d'avoir des impasses sur certains éléments et payer cher l'erreur notamment en matériel ou licence.

A +

[mikedavem]

Beaucoup de bonnes choses ont été dites ici.

Je voulais simplement préciser que le cluster Windows 2008 R2 n'exigeait pas de matériel strictement identique comme son prédécesseur. Il n'existe plus de liste d'approbation du matériel qui sert de base lors de l'installation du cluster.

++

[SQLpro]

Oui, enfin, c'est peut être vrai, mais c'est fortement déconseillé !
Lire : http://technet.microsoft.com/en-us/l.../cc771404.aspx
Notamment :
"Servers: We recommend that you use a set of mat
...
"Microsoft supports a failover cluster solution only if all the hardware components are marked as "Certified for Windows Server 2008 R2." In addition, the complete configuration (servers, network, and storage) must pass all tests in the Validate a Configuration Wizard, which is included in the Failover Cluster Manager snap-in. ching computers that contain the same or similar components.""

A +

[CUCARACHA]

Au sujet des machines identiques...

Je pensais effectivement à 2 machines physiques jumelles non virtualisées pour le serveur SQL pour les bases de données principales.

Les deux bases express c'est juste pour avoir un petit workflow tout simple, en dehors du réseau principal. Leur rôle est simplement de veiller à l'éveil des autres machines.

Au sujet des fermes de virtualisation (dans mon esprit, aussi corrigez moi si je me trompe) qui englobent toutes les autres machines, je ne pense pas qu'il soit nécessaire d'avoir des ensembles strictement identiques. C'est justement tout l'intérêt des machines virtuelles. La preuve c'est qu'on peut prendre une vm sur un petit serveur et la transférer sur une super machine et la VM fonctionne toujours mais plus vite.

Au sujet du nombre d'instances, c'est pour isoler physiquement et géographiquement les installations. Mais la base principale du SI n'est qu'une seule base.

Je vais vous faire un schéma de ma vision de l'installation. Je précise que l'infra n'est pas trop mon métier mais on est obligé d'en faire lorsqu'on est en charge de l'architecture de tout un SI.

Quoi qu'il en soit, merci pour ces précieux conseils.

Laurent

[mikedavem]

Oui, enfin, c'est peut être vrai, mais c'est fortement déconseillé !

Dans un environnement de production il est clair qu'il est plus que conseiller d'avoir une même architecture physique (vendeur, modèle, configuration ...) pour les 2 noeuds ce qui facilite grandement l'administration et évite bien des problèmes. mais dans un environnement de test cela peut avoir des avantages certains ..

Au sujet des fermes de virtualisation (dans mon esprit, aussi corrigez moi si je me trompe) qui englobent toutes les autres machines, je ne pense pas qu'il soit nécessaire d'avoir des ensembles strictement identiques. C'est justement tout l'intérêt des machines virtuelles. La preuve c'est qu'on peut prendre une vm sur un petit serveur et la transférer sur une super machine et la VM fonctionne toujours mais plus vite.

Si vos machines virtuelles hébergent des serveurs virtuelles et que la performance est le cadet de vos soucis alors pourquoi pas ... mais sachez que la virtualisation et SQL Server ne font en général pas bon ménage ..

++

[CUCARACHA]

Re

Comme précisé plus haut, le serveur sql principal est constitué de deux machines redondantes et non virtualisées. Ce sont les autres qui le sont.

++

Laurent