Int égrat ion des syst èm es c lient /serveur Les t ransac t ions DAVID EUDELINE CELAR
LES TRANSACTIONS Objectifs et bases Mesure des performances Propriétés des transactions linéaires Modèles étendus Cas des systèmes répartis Conclusion 2
Le t ransac t ionnel (OLTP) Les systèmes transactionnels fournissent un cadre pour le support des applications critiques en terme de sûreté et de performance. Opérations typiques mises à jour ponctuelles de ligne par des écrans prédéfinis, souvent répétitive, sur les données les plus récentes Exemple Mise à jour d un compte bancaire en débit/crédit Réservation d un billet de train SNCF etc. 3
Le t ransac t ionnel (OLTP) Caractéristiques des applications OLTP Opérations typiques: Mise à jour, ajout de record Type d'accès: Lect/ Ecr Niveau d'analyse: Opérations simples Ecrans: Fixe, fonctionnement répétitif Les quantités d'info échangées sont faibles Haute disponibilité et haute performances Le taille de la est BD est proportionnelle à la production Les données sont récentes Grand nombre d utilisateurs Scalabilité, équilibrage de charge, parallélisme lors de l exécution des requêtes 4
Mesure des perform anc es Benchmark : Banc de Performances Mesurer les performances d un système (matériel / logiciel) sous une charge de travail caractérisant une application type. Cette application peut être définie selon des spécifications écrites par des organismes compétents (ie: modèle TPC) Intérêts: fournir un indicateur fiable et global de qualité des produits comparer les produits entre eux (avec d acheter) fournir des arguments commerciaux Dimensionner son système en fonction de ses besoins ATTENTION à l écart entre Application Réelle et Application «Modèle» 5
Mesure des perform anc es TPC: Transaction Processing Performance Council Groupement de constructeurs, d éditeurs et d utilisateurs né dans les années 1980 pour établir des étalons fiables. Objectifs du groupement Définir des métriques de performances en: tps (transactions par seconde) tpm (transactions par minute) et des coûts par transactions ($/ tps) Spécification du «benchmark» indépendante des systèmes et des logiciels Les propriétés des transactions doivent être conservées. 6
Mesure des perform anc es TPC: Plusieurs types de Benchmarks: TPC-A (1989): Transaction simple de type débit/crédit bancaire. TPC-B (1990): TPC-A réduit à la base de données. Ces deux outils peu représentatif des applications réelles ont été abandonnés au profit d étalon plus représentatif des systèmes modernes TPC-C (1992): Transactions complexes orientées gestion. TPC-D (1995): Outil pour mesurer les performances des applications d aide à la décision.(olap), requêtes complexes et taille des données importante. TPC-D a été revu et corrigé en 1999 par deux nouveaux modèles: TCP-H et TPC-R, toujours orienté décisionnel Applications de type WEB: TPC-W, modèle apparu en 2000 7
Mesure des perform anc es La base TPC-A/B : modèle à simuler $JHQFHV &RPSWHV &DLVVLHUV +LVWRULTXH 7DLOOHSRXUWHUPLQDX[DYHFUqJOHGpFKHOOHVFDOLQJ UXOH 8
Mesures des perform anc es La transaction Débit - Crédit TPC/A et TPC/B 90 % des transactions doivent avoir un temps de réponse inférieur à 2 secondes Chaque terminal génère une transaction toute les 60 secondes (temps de réflexion moyen du caissier) Performance = Nb transactions commises / temps passé Ce modèle est dépassé, il est aujourd hui remplacé par le modèle TPC-C plus complet et plus représentatif TPC-C: Simulation d une application de prise de commande et de gestion de stock (5 transactions différentes) 9
Mesures des perform anc es TPC-W: Applications de commerce sur le WEB Interrogation d une base via des navigateurs (BtoC) Transactionnel sur le Web Commerce électronique (sécurité, paiement ) (BtoB) Benchmarks WebMark :orienté requête HTTP/GET sur des documents statiques SPECWeb: Performance des serveurs (nb de connexion supportées) en statique/dynamique TPC-W :orienté transactionnel: BtoB et BtoC (consultation et achat en ligne) = > Cinq transactions «classiques» 10
Cohabit at ion avec le déc isionnel Les transactions doivent souvent cohabiter avec des requêtes décisionnelles, traitant un volume important de données en lecture. Les architecture matérielles et logicielles doivent trouver un compromis pour satisfaire les contraintes OLAP et OLTP. 11
Les m enac es Problèmes de concurrence pertes d opérations introduction d incohérences verrous mortels (deadlock) Panne de transaction erreur en cours d'exécution du programme applicatif nécessité de défaire les mises à jour effectuées Panne système reprise avec perte de la mémoire centrale toutes les transactions en cours doivent être défaites Panne disque perte de données de la base 12
Propriét és des t ransac t ions Atomicité Unité indivisible : toutes les mises à jour doivent être effectuées ou aucune. Cohérence La transaction doit faire passer le système d'un état cohérent à un autre. Isolation Les résultats d'une transaction ne sont visibles aux autres transactions qu'une fois la transaction validée. Durabilité Les modifications d une transaction validée ne seront jamais perdue 13
Com m it et Abort INTRODUCTION D ACTIONS ATOMIQUES Commit (fin avec succès) et Abort (fin avec échec) Ces actions s'effectuent en fin de transaction COMMIT Validation de la transaction Rend effectives toutes les mises à jour de la transaction ABORT Annulation de la transaction Défait toutes les mises à jour de la transaction 14
Transac t ion sim ple Fin avec succès ou échec Begin_Transaction update update... Commit ou Abort - Provoque l'intégration réelle des mises à jour dans la base - Relâche les verrous - Provoque l'annulation des mises à jour - Relâche les verrous - Rep rend la transaction 15
Effet logique 8SGDWH 8SGDWH 0pPRLUH GH OD WUDQVDFWLRQ &RPPLW $ERUW %DVHVGHGRQQpHV 3RXEHOOH 16
Modèles ét endus Les transactions linéaires répondent bien à des besoins simples qui exigent des réponses de type «tout ou rien» dans des délais rapides. Néanmoins dans certains cas ce modèle se trouve inadapté et il devient alors nécessaire de définir d autres modèles de transaction qui: garantissent les propriétés transactionnelles offrent plus de souplesse dans l exécution Exemple: Transactions passant par l Internet... 17
Modèles ét endus Les critères sont les suivants: Volume des données traitées. durée de la transaction. Interactivité avec l utilisateur. Répartition de la transaction entre plusieurs machines. Tous ces cas de figures supporte mal un comportement «tout ou rien» propre aux transactions linéaires. 18
Point s de sync hronisat ion Introduction de points de sauvegarde intermédiaires (savepoint, commitpoint) Begin_Trans update update VDYHSRLQW update update Commit unité d'œuvre Conservation d u contexte unité d'œuvre 19
Transac t ions Im briquées OBJECTIFS Obtenir un mécanisme de reprise multi-niveaux Permettre de reprendre des parties logiques de transactions Faciliter l'exécution parallèle de soustransactions SCHEMA Reprises et abandons partiels Possibilité d'ordonner ou non les sous-transactions Begin(t 1) Com m it(t 1) %HJLQ7 &RPPLW7 Begin(t1) Commit(t1) &RPPHWW Begin(t2) Begin(t21) Com m it(t21) Abort(t2) $QQXOHWHWW 20
Sagas Groupe de transactions avec transactions compensatrices En cas de panne du groupe, on exécute les compensations 7 7 7 7Q 7 7 &7 &7 21
Transac t ions répart ies OBJECTIF Garantir que toutes les mises à jour d'une transaction sont exécutées sur tous les sites ou qu'aucune ne l'est. EXEMPLE Transfert de la somme X du compte A vers le compte B DEBUT FIN PROBLEME site 1: A = A - X site 2: B = B + X PANNE --> INCOHERENCE DONNEES Le contrôle est réparti : chaque site peut décider de valider ou d annuler sa transaction 22
Transac t ions répart ies plusieurs composantes sur des sites distincts sous le contrôle d'un système transactionnel local avec ses propres procédures de journalisation et de validation. L'atomicité d'une transaction répartie s'applique à l'ensemble des actions de ses agents. L'application directe à chaque agent des procédures locales de validation ne suffit pas Synchronisation des procédures de validation = > "protocole de validation" (compromis entre l'autonomie d'un site (synchro. lâche) et la cohérence des données (synchro forte). 23
Transac t ions répart ies 9DOLGDWLRQjSKDVHV: Phase 1 : envoi par le nœud de validation d'une commande de prévalidation à tous les nœuds subordonnés Phase 2 : attente par le nœud de validation du retour de l'acquittement des pré-validations. Ce retour signifie que toutes les opérations du nœud subordonné ont été correctement effectuées Phase 3 : après le retour de toutes les pré-validation, le nœud de validation envoie l'ordre de validation à tous les nœuds subordonnés Phase 4 : une fois que tous les acquittements de validation sont revenus, le nœud principal valide la transaction Si une erreur est remontée, une non-validation est transmise par le nœud de validation pour effectuer une opération de rollback. 24
Transac t ions répart ies 9DOLGDWLRQjSKDVHV: RMQ: Le protocole nécessite la journalisation des mises à jour préparées et des états des transactions dans un journal local à chaque participant. Performance : ce procédé génère de nombreux messages entre les systèmes qui viennent ralentir la transaction globale Complexité : le procédé repose sur 2 niveaux transactionnels. La complexité de gestion des erreurs s'en trouve donc augmentée 25
Cas Favorable 6,7(&225',1$7(85 6,7(3$57,&,3$17 6,7(3$57,&,3$17 35(3$5( 35(3$5( 2. &200,7 $&. 2. &200,7 $&. 26
Cas Défavorable (1) 6,7(&225',1$7(85 6,7(3$57,&,3$17 6,7(3$57,&,3$17 35(3$5( 35(3$5( 2..2 $%257 $%257 $&. $&. 27
Cas Défavorable (2) 6,7(3$57,&,3$17 6,7(&225',1$7(85 6,7(3$57,&,3$17 35(3$5( 35(3$5( 2. &200,7 $&. 2. &200,7 67$786 &200,7 $&. 28
Transac t ions bloquées Que faire en cas de doute? Demander l état aux autres transactions : STATUS conservation des états nécessaires message supplémentaire Forcer la transaction locale : ABORT toute transaction annulée peut être ignorée cohérence garantie avec un réseau sans perte de message Forcer la transaction locale : COMMIT toute transaction commise ne peut être ignorée non garantie de cohérence avec le coordinateur 29
Prot oc ole arboresc ent TP TP est le standard proposé par l ISO dans le cadre OSI Protocole arborescent Tout participant peut déclencher une sous-transaction Un responsable de la validation est choisi Un coordinateur est responsable de ses participants pour la phase 1 collecte les PREPARE demande la validation Le point de validation est responsable de la phase 2 envoie les COMMIT &RRUGLQDWHXUJOREDO &RRUGLQDWHXUORFDO &RRUGLQDWHXUORFDO 3RLQWGHYDOLGDWLRQ 1RHXGFULWLTXH 30
Transac t ions répart ies Distibution Facteur de complexité pour la mise en œ uvre de l'atomicité (validation et reprise). Nécessiter d'un protocole entre les gestionnaires de transactions pour synchroniser leurs actions. Performance: Pénalisée par les msg et par les mécanismes de validation/ reprise. 31
Conc lusion La complexité et la diversité des besoins des applications client/serveur peuvent rendre difficile la mise en œ uvre des transactions. Les transactions sont fondamentales car elles permettent de garantir les propriétés ACID des échanges client/serveur sans développement supplémentaire. Néanmoins pour ce faire elles doivent s appuyer sur des systèmes permettant d assurer «l acidité» des échanges, ce sont les moniteurs TP (7UDQVDFWLRQ 3URFHVVLQJ). 32
Int égrat ion des syst èm es c lient /serveur Les m onit eurs t ransac t ionnels DAVID EUDELINE CELAR
Int roduc t ion Les moniteurs transactionnels sont spécialisés dans la gestion des transactions. Situés entre les clients et le serveur, ils gèrent les communications en interceptant les échanges. Souvent invisible et méconnu ils sont présents dans la plupart des applications client/ serveur. Les moniteurs TP, après une brillante carrière sur les systèmes propriétaires, se refont une seconde jeunesse avec les systèmes client/ serveur. 34
Int roduc t ion Définition: «Système d exploitation pour le traitement des transactions». Fonctions assurées par les moniteurs TP: Gestion des transactions : Les moniteurs TP garantissent les propriétés ACID des échanges entre le client et le serveur. Gestion des processus : Les moniteurs TP gèrent les processus serveurs, les lancent, les surveillent et équilibrent la charge entre les différents processus. Gestion des communications : Les moniteurs TP assurent la transparence du point de vue du serveur (et du client) sur les middlewares utilisés. /HVPRQLWHXUV73VpFXULVHQWIRQFWLRQQHOOHPHQW OHVFRPPXQLFDWLRQVFOLHQWVHUYHXU 35
Int roduc t ion Pour quel besoins? FOLHQWV FRQQH[LRQV SURFHVVXV 0RGH5$0 ILFKLHUV RXYHUWV / 26V pfurxoh FRQQH[LRQV / 26WLHQW FOLHQWV 7 3 SURFHVVXV 0RGH5$0 ILFKLHUVRXYHUWV 36
Le m odèle : DTP Les moniteurs TP nécessitent des standards car ils interagissent avec des plate formes hétérogènes. Les standards L OSI/ TP de l ISO (Protocole arborescent) Le modèle DTP de l X/OPEN L OTS (Object Transaction Service) de l OMG L X/OPEN a défini un standard de moniteur permettant de gérer les transactions: DTP ('LVWULEXWHG 7UDQVDFWLRQ3URFHVVLQJ) Support de la validation à deux phases Ensemble de spécifications qui permettent d assurer les trois fonctions principales des moniteurs TP. Interfaces: RM, TX, XA. Interfaces de communication propre à chaque type de middleware sous jacent: XATMI (messages), TxRPC( DCE RPC), etc. 37
Le m odèle : DTP Modèle DTP de l X/OPEN Programme d application AP Gestionnaire de transactions TM Gestionnaire de communication CRM Gestionnaire de ressources RM Interfaces standards TX = interface du programme (AP) et du TM XA = interface du RM et du TM intégration de TP Types de RM gestionnaire de fichiers SGBD périphérique 38
Modèle DTP AP (Application) API RM API TX XATMI TxRPC CPI-C RM XA TM CRM Communication entre moniteurs Gestionnaire de Ressources (ex. SGBD) Moniteur de Transactions OSI TP Autres moniteurs 39
Les t rois t iers TP... Les moniteurs TP sont un exemple d architecture client/ serveur à trois niveaux. Découpage fonctionnel de l application: Interface homme machine (IHM ou GUI) Logique applicative Gestionnaire des ressources d arrière plan Les moniteurs TP se placent au niveau de la logique applicative car ils traitent les échanges indépendamment de l interface ou de la ressource. Le moniteur TP permet d isoler la ressource des clients potentiels. 40
Les t rois t iers TP... De fait le moniteur TP: contrôle le trafic en terme de débit (connexions simultanées) gère les processus serveur permettant de traiter les demandes (lancement de nouveaux processus, répartition dans les architectures multi-processeurs, gestion d un pool de serveurs) garantissent les propriétés ACID des échanges. Les communications sont de type «une et une seule fois». Analyse les performances et «marque» les transactions. Équilibre la charge entre les différents processus. Supervise les communications. Permet de faire de la reprise sur panne. Etc. 41
Les t rois t iers TP... Client/ serveur trois tiers, façon moniteur TP MOM Moniteur TP Appli SGBD RPC Appli Appli Domino Niveau 1 : Niveau 2 : Niveau 3 : GUI Logique applicative Données 42
Les t rois t iers TP selon M$ 43
TP léger ou TP lourd? Deux types de moniteurs transactionnel s affrontent sur le marché des applications client/ serveur. Moniteur TP léger ou «73/LWH», initié par Sysbase (1986) pour améliorer les performances de son SGBD. Moniteur TP lourd ou «73+HDY\» Transactionnel léger : Intégration de fonctions transactionnelles au sein du moteur de la base de données. Transactionnel lourd : «Système d exploitation permettant de gérer les transactions».
TP léger ou TP lourd? Transactionnel léger : Les fonctions intégrées dans les moteurs de bases de données s appuient essentiellement sur les procédures stockées. On trouve les fonctions suivantes: Transport de fonctions. La répartition des demandes clients sur un pool de processus (mais les mécanismes sont limités). Mécanisme de RPC propriétaires. Mécanisme de validation ACID pour une procédure stockée donnée. Ces fonctions sont relativement limitées et sont loin de couvrir l ensemble des services rendus par un véritable moniteur transactionnel. Néanmoins les procédures stockées permettent d améliorer les performances.
TP léger ou TP lourd? Caractéristiques du TP léger Gestion des transactions à l aide de procédures stockées écrites avec des langages propriétaires, pas d imbrications, la portée de la validation est limitée (validation à une phase dans la plupart des cas) Pas de portabilité entre les différents SGBD. Incapacité à gérer des ressources hétérogènes (SGBD multi éditeurs) Pas de contexte d exécution robuste. Les appels ne sont pas normalisés (RPC propriétaires)
TP léger ou TP lourd? Performances : Les procédures stockées et les déclencheurs contiennent des ordres SQL pré compilés et chargés en mémoire, amélioration des benchmarks par rapport au SGBD classiques. MAIS le TP léger est beaucoup moins performant que le TP lourd, surtout pour les applications critiques. le TP lourd fournit un contexte d exécution et d optimisation global. Les procédures stockées sont écrites à l aide d outil peu performant car interprétés. (L4G) Le code optimisé du moniteur TP lourd permet d alléger les ressources nécessaires au fonctionnement du SGBD car celui ci se trouve déchargé de certaines tâches. Le TP lourd permet d améliorer les performances sans toucher au matériel.
TP léger ou TP lourd? 73OLWH Grands services pour des SGBD mono éditeurs et des applications de faible criticité avec peu de connexions simultanées. Plus simple à mettre en œ uvre, il fait partie intégrante des offres commerciales des éditeurs de SGBD. Néanmoins il enferre l entreprise dans un système monolithique. 73KHDY\ Bien adaptés aux gros volumes, aux applications critiques nécessitant des temps de réponse contraints. Permet d apparier des composants hétérogènes si ils respectent les standards. Plus difficile à déployer il offre la transparence à l hétérogénéité. Tout dépend du besoin..
Transac t ion et WEB HTTP ne gère pas de session : Les informations utilisateurs ne sont pas gérées nativement part le protocole. Des standards et protocoles sont en cours d élaboration BTP: (Business Transaction Protocol) Proposé par BEA (démonstrateur) Indépendant des protocoles de transport et s appuyant sur XML BizTalk de Microsoft Workflow et transactions plates Rien de mur aujourd hui!!! 49
Princ ipaux m onit eurs (1) Encina de Transarc (renommé TXSeries) issu de CMU (1992), racheté par IBM construit sur DCE (OSF) pour la portabilité et la sécurité transactions imbriquées conformité DTP : Xa, CPI-C, TxRPC CICS de IBM Reprise du moniteur CICS des systèmes OS/ 390 reprise de l existant CICS (API et outils) conformité DTP : Xa, CPI-C Porté sur UNIX et Windows NT (base ENCINA) API : ECI (External Call Interface) pour les RPC, EPI (External Presentation Interface) pour les émulations 3270.
Princ ipaux m onit eurs (1) CICS sur l Internet! :&,&6,QWHUQHW*DWHZD\ HTTP CGI EPI Appli ECI Appli Niveau 1 : Niveau 2 : Niveau 3 : Niveau 4 : Navigateur WEB Serveur WEB Passerelle Serveur CICS 51
Princ ipaux m onit eurs (2) Tuxedo de BEA Éprouvé (depuis 1984), à la base de DTP Issu d un développement d AT&T sous UNIX pour ses besoins propres Supporte l asynchronisme, les priorités et le routage dépendant des données Conformité DTP: Xa, Tx, XaTMI, CPI-C, TxRPC Supporte la majeure partie des plates formes Transactions distribuées, sécurité (API spécifique) Support des middlewares à messages (MessageQ) API:(langages: C, C+ +, COBOL, JAVA, VB) ATMI: clients classiques CORBA: Couplage aux ORB CORBA JOLT: Couplage aux clients JAVA ou aux serveurs d EJB
Tux edo 53
MTS de Mic rosoft Microsoft Transaction Server Intégré à DCOM Partage de grappes de NT (cluster) Les disques sont supposés partagés Allocation des ressources en pool aux requêtes : pool de connexion aux ressources (SQL Server) pool de transactions (support) pool de machines Ne suit pas les standards! 54
MTS de Mic rosoft 55
Conc lusion Trois éditeurs s affrontent :,%0 : L éditeur historique qui traite le transactionnel OLTP depuis vingt ans. %($ : Un jeune en pleine croissance et un rival sérieux. 0LFURVRIW qui offre des solutions pour les composants COM et les produits WIndows Les moniteurs TP sont sur la voie du renouveau... Enjeu essentiel pour le commerce électronique validation fiable reprise et copies partage de connexions partage de charge 56