Discussion :

[voran]

Hello,

Le même débat existe pour ORACLE donc pourquoi pas pour MSSQL Server ?
Je commence par un inconvéniant, sql server ne propose pas de fonctionnement en cluster actif-actif.
En fait, j'ai entendu dire que si avec la version 2005 ... puis en fait non
Rebelotte avec la version 2008 mais je trouve rien là dessus ...
Quelqu'un a-t-il plus d'infos ? Mieux chercher que moi ?

@+

[SQLpro]

Tout dépend de ce que vous entendez par cluster actif actif.

Par essence l'information ne peut se trouver qu'à un seul endroit à la fois au même instant, quel que soit l'outil (Oracle, DB2, SQL Server)... Donc on ne peut pas avoir la même information au même moment sur deux machines différentes. Ce qui est possible dans l'univers des objets (qui ne font pas de persistances de données) n'est pas possible dans l'univers des SGBDR du fait même de leur nature.

De plus le problème est double : pensez vous cluster en terme de haute disponibilité ou bien en terme d'élargissement de la surface d'attaque ?

Si vous pensez en terme de haute disponibilité alors un cluster actif/actif ne sert à rien, et s'avère bien plus couteux (en matériel, installation et administration, sans même parler de licences) que d'autres mécanismes comme le mirroring par exemple (ou encore log shipping).

Si vous pensez en terme d'augmentation de la surface d'attaque, c'est à dire en fait augmenter les ressources afin de servir plus de clients par exemple, alors le débat est tout autre. Économiquement avant de commencer à faire du scale out on commence par épuiser le scale up (autrement dit ne pas commencer à rajouter des machines tant que l'on a pas utilisé un serveur avec 64 processeurs et 256 Go de RAM...) En effet en multipliant le nombre de machines on augmente le cout des licences, le cout d'administration et on diminue le MTBF... c'est à dire que l'on est perdant sur tous les tableaux !
Enfin, si après avoir épuisé le scale up on est contraint au scale out, on doit trouver le moyen de synchroniser les données d'un serveur à l'autre ce qui peut être fait par l'intermédiaire de différents mécanismes :

• réplication (couteux)
• bases de données réparties (fonctionnel - service broker pour MS SQL Server)
• bases de données fédérées (vues partitionnées)

Notez cependant que le cluster Actif/Actif existe bien pour SQL Server, mais que ce ne sera pas la même base sur les différentes serveurs, même si vous synchronisez les données par une réplication par exemple.

Lisez l'article que j'ai écrit à ce sujet sur mon site Corporate (http://www.sqlspot.com/La-haute-disp...-avec-SQL.html)

A +

[voran]

Tout dépend de ce que vous entendez par cluster actif actif.

Comme son nom l'indique, un cluster actif/actif comporte au moins deux noeuds (grappe de serveur)... et actifs.
Les deux noeuds (ou plus) reçoivent des demandes de traitements différentes simultanéments. Ces traitements sont distincts entre chaque noeuds. Les noeuds sont inter-connectés afin d'obtenir des info sur les traitements en cours des autres noeuds.
il ne s'agit pas d'une "simple" réplication et/ou mirroring.
Dans le cas d'un cluster actif/passif. Un seul noeud réalise les traitements. En cas de panne, le noeud passif prends le relais, mais il y a perte de connexions et perte d'informations non commitées. (rollback).

De plus le problème est double : pensez vous cluster en terme de haute disponibilité ou bien en terme d'élargissement de la surface d'attaque ?

Les deux mon capitaine. C'est ce que propose ORACLE Real Application Cluster.

Économiquement avant de commencer à faire du scale out on commence par épuiser le scale up

Ce propos n'a pas sa place ici, nous parlons de cluster, et donc d'au moins deux noeuds. Nous nous trouvons donc dans l'après scale up.

Si vous pensez en terme de haute disponibilité alors un cluster actif/actif ne sert à rien, et s'avère bien plus couteux

Quel incroyable raccourci, digne des meilleurs GPS
Un cluster actif/actif apporte une valeur ajouté importante pour les raisons évoqué dans l'exemple plus bas. Quand au cout, deux serveurs, une licence standard Edition qui inclut l'option RAC, un SAN ne seront pas trop cher par rapport aux fonctionnalité apportées (HA, scalability, sécurité).

Notez cependant que le cluster Actif/Actif existe bien pour SQL Server, mais que ce ne sera pas la même base sur les différentes serveurs, même si vous synchronisez les données par une réplication par exemple.

Tentons de nous comprendre par l'exemple :

J'ai deux noeuds sql server.
un select est en cours à un instant T sur un des noeuds.
Ce noeud tombe pour une raison quelconque.
La session sera elle coupée ?
le select sera il continué de manière complètement transparante pour l'utilisateur ?
Si oui, par quel moyen ?
il sera également possible de monter de version sans interruption de service.

@+

[mikedavem]

Bonjour,

Je prends part au débat

J'ai deux noeuds sql server.
un select est en cours à un instant T sur un des noeuds.
Ce noeud tombe pour une raison quelconque.
La session sera elle coupée ?

La session sera coupée le temps du basculement pour la simple et bonne raison que SQL Server ne permet pas l'accès simultanné de plusieurs process aux fichiers des bases de données. Par conséquent une transaction qui n'est pas achevée quand un noeud du cluster tombe en panne est annulée.

il sera également possible de monter de version sans interruption de service.

Du fait qu'il ne peut exister qu'une seule instance active SQL Server sur un noeud à la fois, vous aurez au moins une coupure le temps du basculement entre les noeuds.

Etant donné que SQL Server est une application à états, le cluster actif/actif ne me paraît pas spécialemment adapté. En terme de haute disponibilité je rejoins SQL Pro, le cluster actif / passif reste la meilleure solution. Après en terme d'élargissement de surface d'attaque c'est une autre histoire ....

Pourriez vous nous indiquer la raison d'un éventuel choix de cluster actif /actif de votre cas ?

++

[voran]

Du fait qu'il ne peut exister qu'une seule instance active SQL Server sur un noeud à la fois, vous aurez au moins une coupure le temps du basculement entre les noeuds.

Etant donné que SQL Server est une application à états, le cluster actif/actif ne me paraît pas spécialemment adapté. En terme de haute disponibilité je rejoins SQL Pro, le cluster actif / passif reste la meilleure solution. Après en terme d'élargissement de surface d'attaque c'est une autre histoire ....

Pourriez vous nous indiquer la raison d'un éventuel choix de cluster actif /actif de votre cas ?
++

Le but premier est de mettre en avant les avantages et les inconvéniants de SQL SERVER, pas seulement des solutions de haute disponibilité avec SQL SERVER.

Je met simplement en avant que la solution RAC proposé par ORACLE n'a pas d'équivalent chez les autres éditeurs SGBD et en l'occurence SQL SERVER.
Me répondre que cela est inutile et couteux n'est pas recevable.
Dois je réellement expliquer l'intérêt d'un cluster de type actif/actif ?

[voran]

...SQL Server est une application à états...

C'est à dire ?

[mikedavem]

Bonjour,

On dit qu'une application est à état lorsque son état réside en mémoire ou lorsque l'état des données change très fréquemment. Ex : Base de données ou messagerie ... Le cluster à basculement est adapté dans ce cas.

A l'inverse vous avez des applications sans état dont l'état ne réside pas en mémoire comme les serveurs Web où vous pouvez faire du load balancing par exemple car chaque application sur chaque noeud est indépendante.

++

[voran]

Bonjour,

On dit qu'une application est à état lorsque son état réside en mémoire ou lorsque l'état des données change très fréquemment. Ex : Base de données ou messagerie ... Le cluster à basculement est adapté dans ce cas.

A l'inverse vous avez des applications sans état dont l'état ne réside pas en mémoire comme les serveurs Web où vous pouvez faire du load balancing par exemple car chaque application sur chaque noeud est indépendante.

++

Bonjour,

Merci pour l'info.

Je suppose qu'on parle du cache de données quand on parle de mémoire du SGBD.
Ne peut on pas considérer qu'un serveur web, comme jakarta tomcat qui fonctionne avec une JVM qui possède son espace mémoire, soit identifié comme une appli à état ?

ORACLE peut donc être considéré comme une application à état. Et pourtant, il possible de faire sur load balancing.

[mikedavem]

Bonjour,
Ne peut on pas considérer qu'un serveur web, comme jakarta tomcat qui fonctionne avec une JVM qui possède son espace mémoire, soit identifié comme une appli à état ?

Sur vos serveurs web (IIS , TOMCAT etc...) chaque demande client est traitée comme une opération indépendante. La charge de chaque demande peut donc être équilibrée indépendemment. On ne peut donc pas considérer ces applications comme des application à état. Le load balancing est alors possible.

ORACLE peut donc être considéré comme une application à état. Et pourtant, il possible de faire sur load balancing.

D'après ce que j'ai vu, effectivement ORACLE permet ce genre de choses par grâce à un add-in via la solution RAC.
Vous pouvez toutefois sur SQL Server "simuler" du load balancing avec les bases fédérés et du clustering ...

++

[voran]

Vous pouvez toutefois sur SQL Server "simuler" du load balancing avec les bases fédérés et du clustering ...
++

ok,
est ce possible à la volée, sans rupture de session ?

[mikedavem]

ok,
est ce possible à la volée, sans rupture de session ?

Pardonnez moi , je viens de me relire , je dis des bêtises. Les bases fédérés et le clustering ne permettent pas de faire du load balancing pour sqlserver...

Pour pouvoir réaliser du load balancing il faudrait qu'il soit géré par le moteur de base de données lui même comme c'est la cas avec oracle ....

Mais revenons au sujet du début peut être , il est possible de faire du cluster actif /actif comme le mentionne SQLPro... et tout comme lui je ne le conseille qu'en dernier recours.


++

[voran]

Notez cependant que le cluster Actif/Actif existe bien pour SQL Server, mais que ce ne sera pas la même base sur les différentes serveurs, même si vous synchronisez les données par une réplication par exemple.

Lisez l'article que j'ai écrit à ce sujet sur mon site Corporate (http://www.sqlspot.com/La-haute-disp...-avec-SQL.html)

2 noeuds sql server par exemple, mais avec 2 bases différentes sur chacun des servers...
non synchronisé...
???
Comment cela peut marcher ???
???
une mise à jour sur une des bases n'est pas connu de l'autre base ...

[voran]

Notez cependant que le cluster Actif/Actif existe bien pour SQL Server, mais que ce ne sera pas la même base sur les différentes serveurs, même si vous synchronisez les données par une réplication par exemple.

Lisez l'article que j'ai écrit à ce sujet sur mon site Corporate (http://www.sqlspot.com/La-haute-disp...-avec-SQL.html)

Après lecture du document, il apparait en effet que SQL Server permet un fonctionnement en cluster actif/actif.
Cependant, ce mode de fonctionnement ressemble plus à un cluster actif passif dont le basculement a été automatisé. En effet, un des noeuds n'est accessible qu'en lecture seule. Cela est plus proche d'ORACLE DATA GUARD.

ORACLE va plus loin.

1) ORACLE Real Application Cluster (RAC) propose au moins 2 noeuds actif simultanéments. En cas de défaillance d'un noeud, l'accès à la base sera disponible via le ou les noeuds restant, et ce sans aucune latence.
Comment SQL Server reproduit cette fonctionnalité ?

2) Transparant Application Failure (TAF) ajoute une complète transparance pour l'utilisateur en cas de panne de l'un des noeuds. Le traitement en cours est repris là ou il en était, et terminé sur un noeud disponible.
Comment SQL Server reproduit cette fonctionnalité ?

[SQLpro]

1) ORACLE Real Application Cluster (RAC) propose au moins 2 noeuds actif simultanéments. En cas de défaillance d'un noeud, l'accès à la base sera disponible via le ou les noeuds restant, et ce sans aucune latence.
Comment SQL Server reproduit cette fonctionnalité ?

Clustering actif/passif ou mirroring de base de données. La basculement est automatique.

2) Transparant Application Failure (TAF) ajoute une complète transparance pour l'utilisateur en cas de panne de l'un des noeuds. Le traitement en cours est repris là ou il en était, et terminé sur un noeud disponible.
Comment SQL Server reproduit cette fonctionnalité ?

SQL Server n'accepte pas de reprendre le traitement quelque soit le mode cluster ou miroir. La transaction sera considérée comme rollbackée. Cela n'empêche pas le client de relancer sa demande sur le nouveau serveur disponible (soit nœud cluster devenu actif, soit miroir basculé), les temps de commutation étant en pratique de quelques secondes.

Demandez vous combien de personnes utilisent réellement RAC sous Oracle... Par exemple à la socité général, grande consommatrices de SGBDR en tout genre (Oracle, SQL Server), le RAC n'a jamais été mise en œuvre... faible gain potentiel, cout exorbitants, pour peu de risques couverts. Car RAC nécessite des serveurs physiquement proches les uns des autres et ne répond pas à la problématique majeure des SI : comment assurer une continuité de service en cas de désastre majeur : incendie, dégât des eaux, terrorismes... alors que le mirroring de BD permet des distances illimitées (over http....)

A +

[voran]

Clustering actif/passif ou mirroring de base de données. La basculement est automatique.

avec coupure de session + rollback de la transaction en cours, sympa merci.

SQL Server n'accepte pas de reprendre le traitement quelque soit le mode cluster ou miroir.

SQL Server ne sait pas reprendre le traitement

les temps de commutation étant en pratique de quelques secondes.

Il y a plutôt intérêt.
Pareil avec ORACLE DATA GUARD.

Demandez vous combien de personnes utilisent réellement RAC sous Oracle...

Tiens c'est bizarre , pour nous c'est plutôt la tendance inverse ... Nos clients grands comptes sont de plus en plus demandeurs. certains avec data guard en plus.
Pour ce qui est de sql server, le mode cluster, quel qu'il soit, n'a pas la côte ... et c'est pas faute d'essayer. partenariat avec microsoft oblige.

...Car RAC nécessite des serveurs physiquement proches
les uns des autres et ne répond pas à la problématique majeure des SI : comment assurer une continuité de service en cas de désastre majeur : incendie, dégât des eaux, terrorismes... alors que le mirroring de BD permet des distances illimitées (over http....)

C'est logique, puisqu'il y a ORACLE DATA GUARD pour répondre à cela.

ORACLE RAC apporte un plus.
Et lorsqu'il est couplé avec DATA GUARD, il assure alors un niveau de haute disponibilité que ne peut prétendre sql server.

[SQLpro]

Et lorsqu'il est couplé avec DATA GUARD, il assure alors un niveau de haute disponibilité

Avec des machines dont la distance est faible, cela ne présente pas beaucoup d'intérêt....
Que ferez vous en cas d'incendie, tremblement de terre ou inondations ?

A +

[voran]

Avec des machines dont la distance est faible, cela ne présente pas beaucoup d'intérêt....
Que ferez vous en cas d'incendie, tremblement de terre ou inondations ?

A +

Et je vous répète qu'en cas de catastrophes naturelles, je suis protégé par ORACLE DATA GUARD.
Comme vous pouvez le lire dans une étude publiée dans le "Disaster Recovery Journal", les pertes de données ne sont pas dues pricipalement à des catastrophes naturelles, mais à des pannes matérielles et à des erreurs humaines.

ORACLE DATA GUARD ET ORACLE RAC ensemble, permettent d'assurer une continuité de service inégalé (en tout cas par rapport à microsoft) pour les applications critiques.

La société générale n'est donc, à mon grand étonnement, pas si rigoureuse en terme de sécurité des données.

Nous avons plusieurs client (par exemple dans le domaine de la grande distribution) qui exigent ce niveau de continuité de services. Ils ne sont pas spécialement pro ORACLE, mais ils n'ont pas vraiment eu le choix.

Et en terme de coût :
Votre solution de database mirroring avec sql server en géo cluster est généralement asynchrone, et il existe une problématique de reprise de données.
Pour bénéficier des avantages du stretch cluster avec un géo cluster, il faut faire appel a des solutions tiers telles que EMC et UNISYS très couteuse.
Cette solution va donc facilement égaler, sinon dépasser une solution avec ORACLE.
(source webcast techdays 2008 - haute disponibilité avec sql server 2005)

bye