Le concept Client/Server CERN fondé en 1954, 14 états membres, Laboratoire Européen pour la recherch sur la Phisique des particules. 3500 titulaires, 3500 visiteurs, 25 nationalités DG: Carlo RUBBIA Etats hôtes : Suisse - France 5 Accelérateurs principaux dont le LEP, le + grand accélérateur du monde (27 KM de circonférence, coût: 1 milliard de $, 10000 composants principaux) 57 expériences, dont 4 grandes sur le LEP, 216 instituts et universités y sont représentés) Le concept Client/Server Lausanne, le 5 Septembre 1991 hemmer@cernvm.cern.ch

Topics Le modèle client/serveur Choix du hardware Réseaux Example CERN Bases de données distribuées Tolérance aux pannes Futur des SGBD

Client/Server Model Sans rapport avec les BD Separe l'application (client ou demandeur de services) du fournisseur de service(s) (serveur) Le serveur gère les resources Le client interface (communique) au serveur Le client est géré par l'utilisateur Très ancien modèle (VM/CMS, Berkeley Unix ...) Implique une forme de communication entre client et serveur (Mémoire partagée, RPC, Protocole de transport...)

example VM/CMS User VM R; Print a file (Pseudo) communication VMCF, IUCV, Spool, SNA, X.25 ... Printer (Local or Remote) Server VM Printer Device

example Unix User process lpr -P printer (Pseudo) communication IPC : pipes, TCP sockets, Decnet sockets... Line printer daemon (local or remote) Printer Device

example X/Windows Screen Device X Server (Pseudo) communication Application (e.g. spreadsheet, database ...)

Tout ensemble ... Machine A Print Pie Chart of Last Year Sales Per Country... Machine B X Server Database application Machine C Database server Machine D Printer Server

Pour et Contre La ressource est séparée de son utilisation (OO) Gestion des ressources plus aisée La couche réseau est naturelle L'application ignore la façon dont le serveur fonctionne Permet un meilleur usage des ressources (Load sharing) Downsizing Le serveur doit se soucier du partage de ses ressources La communication doit être totalement spécifiée La gestion des ressources et du réseau est plus compliquée

Considérations Techniques Multitâche Multithread Protocole de réseau Coût de taux de transfert Flexibilité Heterogénéité Interoperability Impact de la technologie Example : Shift

SHIFT ne concerne pas directement Oracle au CERN, mais ce type d'utilisation de resources pourrait y être appliqué. BUT : utiliser les stations RISC bon marché afin de fournir deux fois la puissance de calcul existante au CERN au 10ème du prix. Utiliser des techniques EXITANTES (nous voulons être simples et conservateurs). Traiter le problême du coût en temps CPU dû au traitement des protocoles -> Ultranet pas FDDI (IBM 1MB = 0.8 CPU) Serveurs de disques -> coût CPU des I/O non imputé au serveur de CPU. Serveurs de disques et de bandes -> flexibilité. On pourrait ajouter un serveur de BD REPRODUCTIBLE Intérêt croissant, aussi bien chez les utilisateurs que chez les constructeurs. Ex: CHEOPS. Shift U l t r a n e SGI SGI DN 10K DecStation Sun DN 10K IP Router Site infrastructure

Un example de traitement sur SHIFT TAPE SERVER SHIFT1 JOB CPU lire fichier /shift/shd01/xyz rtcopy DPM: sfget ? rfio DISK SERVER Flux de contrôle Flux de données

Choix du Hardware Séparer le choix client/serveur Hardware & Operating system Standard environments (e.g. Unix, OSF vs. VMS) Standard Look & Fell (e.g. Motif, OpenLook, MS Windows, Apple L&F...) Fault tolerance support Ability to support networking Choix du Hardware Séparer le choix client/serveur Client basé sur le L&F Serveur basé sur les performances, les services fournis et la connectivité Protocoles STANDARDS !! (p. ex.TCP/IP) Relatif à l'activité Impact de la technologie (p.ex. HP 700, N-Cube 2) Downsizing peut épargner de l'argent Preserver l'investissement existant (p.ex. l'infrastruture réseau) Préserver l'environnement existant

Réseaux Locaux Indépendant du client/serveur ou des bases de données LANs provide underlying HW infrastructures, and usually gateways to external world They cannot be dissociated from the netwrok protocols The protocol use on Minis/Mainframes is usually well defined Many PC vendors provide proprietary protocols which must be supported in some case (e.g. Novell, Appletalk) Usually coexistence of protocol stacks and TCP/IP stack is allowed Local area management is very complex ( JNG foil) LAN protocol management is very complex (but tools/standard are coming e.g. SNMP, NetView) Some sort of Global centralized management is always needed (e.g. official IP numbers, HW E'Net numbers) Réseaux Locaux Indépendant du client/serveur ou des bases de données Impact dans l'environnement PC/Mac Doit être supporté par leSGBD Protocole Gestion

Equipement CRAY X/MP 48 (Unicos 5.1.9) IBM 3090/600 E-VF (VM/XA SP2.1) CRAY : Batch, 5400 utilisateurs enrégistrés, 50 Giga-octets, connection au robot. IBM : Interactif et Batch, 6000 utilisateurs enrégistrés, 750 actifs, 220 Giga-octets, connection au Robot. Siemens = Fujitsu M382 : Batch et ADP. VAX: 2 Cluster centraux totalisant 50 Giga-Octets et 3500 utilisateurs enrégistrés. Macs : en réalité 2500 Impossible de compter exactement le nombre de Mac, PC. Change chaque jour. Très hétérogène (Système d'exploitation, taille, interfaces) Il y a une tendance à vouloir standardiser le système d'exploitation sur Unix. Mais quel Unix (OSF, ATT ...) Timide apparition de terminaux X Equipement CRAY X/MP 48 (Unicos 5.1.9) IBM 3090/600 E-VF (VM/XA SP2.1) Siemens/Fujitsu 7890 S (VM/HPO 5) 250 VAX, µVAX & VAXStation (VMS) 50 VAX, µVAX & VAXStation (Ultrix) 250 Apollos (Domain OS 10.2) 100 Suns 2000 MacIntosh's 1200 IBM PC et compatibles (DOS et Unix) RT/PC, RS 6000, Silicon Graphics Norsk Data, PS/2, DecStations ...

Réseaux Ethernet FDDI Ultranet Token Ring (Domain) Token Ring (IBM) Ethernet installé dans quasiment tous les bureaux, toutes les zones d'expérience. FDDI sert d'épine dorsale a de nombreux troncs d'Ethernet, mais est aussi utilisé expérimentalement sur IBM 3090, Sun (Cray GW), Apollo... Ultranet installé en Decembre, et servira principalement au projet SHIFT. Avantage : le protocole est traitée sur la carte, libérant ainsi le processeur hôte. Token-Ring IBM utilisé principalement dans le systèeme de contrôle du LEP. HPPI sera utilisé expérimentalement pour lier un IBM 3090 privé (L3) a sa zone d'expérience. Cernet après des annéées de service (1975) a été arrêté en 1989. RS 232 pour connecter quelque 3000 terminaux. Réseaux spéciax tels que un lien IBM-Apollo a travers un canal IBM. Oublié : LocalTALK bien sûr. Comme pour les ordinateurs, très hétérogène. On pourrait croire que le protocole de réseau cacherait cette hétérogènéité, mais ... Réseaux Ethernet FDDI Ultranet Token Ring (Domain) Token Ring (IBM) HPPI Cernet (†) RS 232 Réseaux spéciaux

Protocoles de réseaux TCP/IP UDP/IP Decnet SNA Appletalk Volonté d'adopter les standard ISO, mais ils ne sont pas encore là. TCP est disponible sous cansiment toutes les machines sauf quelques VAX/VMS. Liason Internet. UDP est surtout utilisé dans le système de contrôle du LEP, ou par des standards de plus haut niveau (exemple NFS,NCS...) DECNET sur VAX(Ultrix et VMS), IBM/VM, pas sur Mac et PC (Phase IV!). Liaison extern HEPNET. SNA lie quelques IBM (dans et hors site) ainsi que des NORD et des VAX/VMS. Appletalk pour MAC seulement Novell pour compatibles PC conjointement a TCP/IP. X.25 utilisé principalement pour l'accès externe par terminaux et le courrier électronique. Liaison satellite. ISO en cours d'investigation Protocoles spéciaux : ex: MIL 1553 Protocoles de réseaux TCP/IP UDP/IP Decnet SNA Appletalk Novell (SPX/IPX) X.25 ISO/OSI Protocoles spéciaux ...

Infrastructure des réseaux Cray XMP 48 Sun Vue extrèmement simplifiée du centre de calcul. Les stations de travail puissantes commencent à être utiliséees pour la physique (consommatrice de temps CPU) CTC IBM 3090 E Sun Siemens 7890 S FDDI VAX Cluster CERN VAX Cluster ENG

Le réseau du CERN

Bases de données Distribuées Traitement distribué Serveurs de base de données Base de données distribuées Example : CERN

Traitement Distribué Network Database Server Database Engine

Bases Distribuées Network Portugal Database Server Database Engine UK Sales Network Database Server Database Engine Switzerland

Serveurs de Bases de Données Client Client Client Server Server . . . Server Database Server Database Engine

Transaction Processing Monitors One server/client consumes memory Unix history Multithreaded server improves Xaction troughput TP routes to server Load balancing Dynamic management of servers Xaction monitoring Conclusion more management can be given to the TP Client Client Client Transaction Processing Monitor Multithreaded Server Multithreaded Server . . . Database Server Database Engine

Topologie SQL*NET au CERN This is want we want to achieve Explain connectivity (Decnet on VAX, IBM...) Novell, Appleshare Databases where there is disk space+CPU LEP CS (later) RT/PC, Apollos: SQL*NET Xenix: other sol. (later) External networking: BERKELEY Cray missing because not yet SQL*NET, but only client is here of interest (Cray is a batch machine at CERN) External links to LBL (FORMS application Decnet, SLAC TCP/IP) Reducing the number of DB helps DB management Siemens 7890 S VM/HPO CTC VTAM IBM 3090/600 6 VF - VM/XA 8232 CLC Cray X/MP 48 TCP/IP Sun 8232 3732 TCP ... Decnet IP Central VAX/VMS Cluster LAVC LAVC LEP PS Ultrix Apollo Ultrix Ultrix Ultrix TCP Ultrix RT PC Ultrix TCP IPX TCP TCP Fastpath Novell Sun Appletalk Mac IBM PC Mac IBM PC IBM PC Mac IBM PC Mac Mac IBM PC Mac IBM PC Mac Apollo IBM PC

Le Système de contrôle du LEP Le systême de contrôle de LEP consiste en une interconnection de TR. Il y en a 2 pour le LEP, l'anneau machine n'est pas nécessair à l'arrêt. Le TR au dessus de TDM (Coax ,Fibre) TR : Apollo, RT/PC, PC Xenix et PCA. TCP/IP PCA, ECA : MIL 1553 B Gestion du réseau est stockée dans Oracle PC Xenix, PCA, ECA pas de SQL*Net ==> problème SPS LEP Domain Lab et bureaux PCR Pbar Dev Centre de calcul

Architecture du Logiciel RT/PC, Apollo -> SQL*Net directement au serveur Oracle (LEP DB : VAX/VMS) PCA, Xenix: RPC -> Expliquer Example : donner information de cablâge du chassis VME 1234 methode 1 programme C methode 2 rsh SQL*PLUS, mais très long pour VMS IBM RT PC Apollo IBM PC/AT PCA Application Application Application Application RPC client RPC client SQL*Net SQL*Net RPC Servers SQL*Net Application Servers Oracle SQL*Net Oracle Server DataBase Server

EMDIR Oracle même probleme données : construire un répertoire à accès distribué, utlisant Oracle sur VAX/VMS (connectivité a l'epoque). Mais connection à Oracle peut prendre plusieurs minutes sur VMS surchargé. On veut < 5 sec. Donc serveur connecté en permanence à Oracle 10000 adressed électroniques, accéde par 200 ordinateurs de par le monde. Interface avec USERREG (SQL*FORMS sur VM). Portable. Projet de routeur de mail intelligent. Interface pseudo intercative sur BITNET/EARN Interface Utilisateur Oracle Serveur EMDIR Client EMDIR RPC RPC Niveau Transport Niveau Transport Réseau

Performance Performance pas benchmark !! Utrix(8530) à VMS (8700). machines vides, résaux inutilisés, performance maximale. Sélection d'un LONG RAW de plus en plus grand Quasi linéaire Ultix/VMS 100 KB/s : acceptable VMS à VMS : 2 MB/s local, 0.6 MB/s Decnet Performance ms Decnet Tcp/Ip Local KB

Fault Tolerance Accès aux données Recovery Tolérance aux pannes totale Sometimes data access must be guaranteed (e.g. air line reservation, bank xactions...) In case of HW or SW fault, one must be able to recover even by cancelling uncomitted xactions. Full fault tolerance currently only by HW redundancy, but some of its functionality may be achieved thru DC Very few HW solutions (Tandem) Sometime the underlying OS gives support (e.g. VMS shadow disks) Some RDBMS allow part of the system to be down while the rest remain online (e.g. Oracle table spaces) Some systems provide fault tolerance support thru OS (e.g. Sybase companion server in VMS Clusters) Some systems provide SW replication but still in research Most of RDBMS provide checkpoint/recovery Sometime restart operation are critical (e.g. banking systems) Fault Tolerance Accès aux données Recovery Tolérance aux pannes totale Hardware Support du système Software Tandem's non-stop SQL

Challenges Utilisation de CASE Distribution pour productivité Distribution pour performance Manque d'outils de gestion Le DBA doit s'occuper de réseaux Le DBA doit s'occuper de plateformes multiples

Futur des SGBD commerciales Types de données + riches (images, voix, etc...) Orienté Objet Ouvert (RDA) SGBD répliquéés SGBD Real Time Transaction Monitors Securité Gestion globale