Discussion :

[orafrance]

Par ailleurs, la techno de clustering et de réplication de la RAM permet de s'affranchir des limites physiques liées au bases.

C'est justement ce que j'aimerais comprendre. Comment répliquer la RAM sans lien ULTRA rapide entre les noeuds ? Quel gain de perf dans les I/O RAM si les contentions sont dans la réplication ? Je ne doute pas que ce soit une architecture intéressante mais 8To de RAM mutliplié par le nombre de node plus l'architecture à mettre en oeuvre ne doit pas être à la portée de toutes les bourses.

[privatelab]

Vous avez raison...

le point de contention de cette archi devient le réseau.
En pratique, il faut un réseau gigabits, mais le vrai problème réside sutout dans les conflits de mise à jour de la même donnée sur plusieurs noeuds.
Pour résoudre cela, il y a deux stratégies :

1 : réplication synchrone avec lock pessimiste des objets en cache
2 : replication asynchrone avec gestion de lock optimiste

Si la 1ère solution apporte les meilleures garanties en terme d'ACIDité du système, en pratique le lock pessimiste diminue les perf de l'ensemble.

La 2ième est celle en oeuvre à l'EASDAQ; ils tolèrent les inconvénients d'avoir potentiellement des rollback a posteriori (verrou optimiste) mais ils y gagnent en fluidité. Leurs transactions sont de type idempotentes, ce qui leur permet de rejouer automatiquement celles qui partent en rollback; il y a un certain % de rejeu mais au total cette solution est bcp plus rapide.

Et concernant votre remarque sur le coût, c'est effectivement cher à mettre en oeuvre mais il faut le comparer à du Mainframe pour avoir le même genre de service; du coup en relatif, c'est assez économique.

Cdlt,
Laurent.

[orafrance]

Finalement je pense qu'on va arriver à ce mettre d'accord

Si j'ai bien compris : Vous proposer de cacher et répliquer le SGBD dans des serveurs distribués pour mieux assumer les gros stresses du SI et une haute dispo. Vous proposez alors de tout simplement supprimer la notion de SGBD.

C'est bien cela ? Si c'est le cas, pour supprimer le SGBD qui apporte une organisation des données largement éprouvé ?

[Marc Lussac]

Ca aurait été bien qu'on ait eu l'autorisation de reproduire l'article d'origine ici, ce qui aurait certainement facilité la discussion.

"privatelab" ca vous serais possible d'obtenir l'autorisation de reproduction de votre article sur developpez.com, et si vous l'avez pourriez-vous l'envoyer à Fred_D (resp de rubrique SGBD) ?

[orafrance]

c'est vrai que n'ayant pas lu l'article c'est pas évident

[privatelab]

oui, c'est presque ça...
je ne propose pas de supprimer le SGBD (bien que le titre de l'article puisse le faire croire), mais juste de dire que j'ai vu (plusieurs fois) des archi où la base est sortie du chemin critique.

On perd effectivement en souplesse dans l'organisation des données, mais si vous me relisez bien, dans l'exemple de l'EASDAQ, il y a quand même une base notamment pour faire du reporting statistique avec des outils SQL.

L'article extrapole ces exemples et je me cite :

...tout cela n'en encore qu'au stade préhistorique...

voilà, le but était de faire savoir que l'on peut faire sans SGBD dans certains cas que j'ai vécus et par extrapolation j'ai étendu l'exemple.

Pour la publication de l'article sur developpez, je vais voir avec 01...je vous tiens au courant.

cdlt,
Laurent.

[Marc Lussac]

Pour la publication de l'article sur developpez, je vais voir avec 01...je vous tiens au courant.

Merci beaucoup

[orafrance]

voilà, le but était de faire savoir que l'on peut faire sans SGBD dans certains cas que j'ai vécus et par extrapolation j'ai étendu l'exemple.

Très bien

J'espère pouvoir lire votre article pour apporter d'avantage à ce débat qui était partie sur de mauvaises bases

[Research Am]

J'ai bien hâte de voir si nous allons pouvoir lire cet article, de ce côté de l'Atlantique (Montréal), bien peu de bibliothèque ont 01net dans leur périodique (dont celle de mon arrondissement ne l'a pas)

Research

[privatelab]

voilà l'article en ligne sur le site de 01 :
http://www.01net.com/editorial/28395...lationnelles-/

je vous préviens : je ne répondrai plus aux questions qui ont déjà été posées et auxquelles j'ai déjà répondu. (ptite fatigue)
Si vous avez un doute, merci de relire mes différents posts avant de me tirer une balle dans la tête. (grosse fatigue)

et svp, merci de penser que je ne veux de mal à personne.

Cordialement,

Laurent.

PS : vous avez le sens de la formule !

...ce débat qui était partie sur de mauvaises bases

[Luc Orient]

Je me permets d'intervenir dans ce débat afin de rectifier une inexactitude.

Dans son message du 7/10

"...
Concernant vos remarques sur des archi basées mainframe, je dois avouer ne pas en avoir d'experience concrête.
Cela dit, chez nous le sysplex est promu par IBM depuis des années, mais aucune mise en oeuvre pratique n'en a jamais été faite.
... "

Par ailleurs, dans son message du 26/10

"...
Et oui, chez BNPParibas (où je travaille depuis 10 ans), aucun des SLAs ..."

Chic ! Un collègue !
Il se trouve que moi aussi je travaille chez BNP Paribas et ceci depuis plus de 10 ans.

Le problème, c'est que chez BNP Paribas, le SYSPLEX préconisé par IBM a bien entendu été mis en oeuvre sur le site majeur de production (4 membres SYSPLEX avec 4 DB2 et 4 IMS/TM).
Il existe d'autres serveurs z/OS ou le SYSPLEX n'est pas installé mais ils ne sont pas majeurs pour l'entreprise.
Alors que penser de quelqu'un qui prétend défricher de nouvelles architectures et donner des leçons aux DBA de la terre entière et qui ne sait même pas ce qui se passe dans sa propre entreprise ?
Je m'interroge quoi !

Un DBA "de terrain" les mains dans le cambouis et loin des délires des magazines.

DB2 for z/OS
COBOL
IMS/TM
JCL
REXX

Vive les dinosaures !

[privatelab]

Bonjour collègue,

Le sysplex est sûrement en oeuvre (si vous le dites) mais du coup si cela fonctionnait si bien comment se fait-il que le mainframe ait connu presque 3 jours d'interruptions il y a environ 3 semaines....
on nous a expliqué qu'il s'agissait d'un bug dans la commande de flashcopy du microcode ???
sysplex ou pas, notre business (hébergé sur le SYSA) a été plongé dans le noir...le site de secours ayant eu qques problèmes à l'allumage...

Je m'interroge donc à mon tour....

et puis de toute façon, la question n'est pas là...si vous relisez mes post, vous noterez que d'après moi, il n'y aurait qu'IBM pour pouvoir assurer du 100% de dispo...mais comme nous l'avons vu il y a 3 semaines, même chez BNP (l'un des plus gros clients d'IBM) le mainframe est faillible.

Bref, je n'oppose pas une archi versus une autre, je dis simplement que j'en ai vu d'autre moins classiques qui fonctionnent sans SGBD.

et où avez-vous vu/lu que je relègue les technos mainframe au rang de dinosaure ?

Au plaisir de vous croiser un jour,

Laurent.

et je ne donne des conseils à personne...mais quelle mouche vous pique pour exprimer une telle hargne ?

[Luc Orient]

Le sysplex est sûrement en oeuvre (si vous le dites) mais du coup si cela fonctionnait si bien comment se fait-il que le mainframe ait connu presque 3 jours d'interruptions il y a environ 3 semaines....
on nous a expliqué qu'il s'agissait d'un bug dans la commande de flashcopy du microcode ???
sysplex ou pas, notre business (hébergé sur le SYSA) a été plongé dans le noir...le site de secours ayant eu qques problèmes à l'allumage...

Encore une fois, le problème vient du fait que l'on ne parle pas de la même chose.
Il existe plusieurs serveurs z/OS chez BNP Paribas. La machine que vous citez (SYSA) n'est effectivement pas en mode SYSPLEX.
Mais il existe un autre serveur (qui traite un volume de données beaucoup plus important à mon sens) qui lui est en mode SYSPLEX. Par exemple, à cette machine sont reliées l'ensemble des agences de BNP Paribas.
Je souhaitais juste rectifier l'affirmation fausse qui consiste à dire que le mode SYSPLEX n'est pas en oeuvre à BNP Paribas.

Quand à l'incident que vous évoquez, je ne vais sûrement pas polémiquer à ce sujet sur un forum public.

Enfin, l'allusion aux "dinosaures" n'était pas dirigée contre vous, il s'agissait juste d'un clin d'oeil pour les lecteurs du forum vu que ce terme a souvent servi à qualifier les serveurs mainframe.
N'oublions pas que la machine z/OS la plus puissante d'IBM (enfin jusqu'à peu puisqu'une autre vient juste de sortir) avait comme non de code T-REX ...

[privatelab]

Ok, merci de cette précision.
et mea culpa pour avoir - à tort - dit que le sysplex n'était pas mis en oeuvre chez nous...cela dit, j'avais quand même pris la précaution de dire que je n'avais pas d'expérience concrête du Mainframe...

en cherchant bien, on trouve toujours plus fort que soi.

cela dit, si vous le souhaitez, je voudrais avoir votre avis sur la panne du SYSA, en message privé bien entendu.

A bientôt,

Laurent.