Yearly User CC-Lyon Summary J. Brunner CPPM Antares.

Présentation au sujet: "Yearly User CC-Lyon Summary J. Brunner CPPM Antares."— Transcription de la présentation:

1 Yearly User Meeting @ CC-Lyon Summary J. Brunner CPPM Antares

2 Man Power Situation 2 Permanent Non-Permanent Setup of LCG

3 Budget development 3 Setup of LCG Approximately constant over last decade

4 Budget share 4

5 Development of Power Consumption Cooling crisis finished Power need reduced However price increases 5

6 Number of Cores in Batch Farm Doubled since 2009 : 18000 (!) Shared between GridEngine and LCG 6

7 Batch farm usage About 75 groups, slight increase over time 7

8 Batch farm usage 2012 Clear dominance HEP, Astro 10% 8 115 Mhrs HS06 per month

9 Batch farm usage 2013 Still dominance HEP, Astro 13.6% 9 140 Mhrs HS06 new groups per monthLSST, Euclid

10 Batch farm sharing (2012) HEP = LHC Astro : Antares 2 nd user –Total 0.171*0.1 = 1.7% –18000 * 1.7% = 300 cores –2 Mhrs HS06 per month KM3Net : Could take role of Antares 10

11 Batch farm in 2012 per month Large availability, smooth distribution –Broken –Wait –Run 11

12 Batch farm in 2013 per month Less smooth : GE upgrade, SL5  SL6 –Broken –Wait –Run 12

13 Antares batch farm usage 2012 Between 1-2 Mhrs per month 13

14 Antares batch farm usage 2013 About 3 Mhrs per month, little antares_prod 14

15 Antares batch farm usage Long term trend khrs in HS06 per year Real usage starts with data taking …. 15 2004200520062007200820092010 1046047914176 51413 01412 150

16 Mass Storage Tapes on HPSS with large buffer disks HEP even more dominant as for CPU 16

17 Antares mass storage 2013 About 200 TB per year on tape (HPSS) –Processed data plus MC (raw data 5TB/year) Currently about 100 TB on disk (sps) Delicate point : Garbage collections ! Most stored files ARE garbage 17

18 Services de base de données 18 Client Oracle Services Mysql Services PostgreSQL Services Internet

19 Infrastructure : Oracle 12 machines in production mode –13 DB clusters (11gR2) –56 TB total –515 accoutns 10 DBs with Data Guard (11gR2) 2 emergency servers 19

20 Infrastructure : Oracle RACDGAccountsSize Internal applications CC2Y341300 GB Development2N72500 GB GRID services2Y46500 GB EDMS2N2016 GB Backup catalogs2Y1710 GB Symod : monitoring tools CC2Y36600 GB Experiments2Y321200 GB IRODS2Y39200 GB Atlas4N541100 GB AMI4Y59420 GB Opera2Y1850 000 GB 20

21 Data Guard Infrastructure : Oracle 21 Switch FC 4GB/s 12 Serveurs avec double alimentation Lien 1GB/s Oracle PILLAR Redondance disque : RAID 50 + Spare 185 To SATA 30 To FC Lien 4GB/s Public IBM V7000 Redondance disque : RAID 6 + Spare 170 To SATA Lien 10 GB/s …

22 Infrastructure : Mysql 2 machines de production pour Mysql –4 serveurs Mysql (Actif – Passif ) –599 Bases de données –600 comptes –80 Go utilisés 1 machine de test pour LSST (5 To) 1 machine dédiée aux besoins spécifiques à certaines expériences –L’administration du serveur Mysql est gérée par l’expérience 22

23 Infrastructure : PostgreSQL 2 machines de production pour PostgreSQL 2 serveurs PostgreSQL ( Actif – Passif) –69 Bases de données –77 comptes –77 Go utilisés 2 serveurs PostgreSQL ( Maître –Esclave) –1 Base de données et 1 seul compte –440 Mo utilisés 3 serveurs PostgreSQL ( Maître –Esclave) E-tricks –Maître CC / esclave Impérial College et Luxembourg 23

24 Infrastructure : Mysql / PostgreSQL 24 Switch FC 4GB/s Lien 1GB/s Oracle PILLAR Redondance disque : RAID 50 + Spare 185 To SATA 30 To FC Lien 4GB/s Public Lien 10 GB/s IBM V7000 Redondance disque : RAID 6 + Spare 170 To SATA Mysql PostgreSQL Mysql LSST

25 Network connections Network managed by CC-Lyon Traffic load map One end point : Antares site 25

26 Network : External lines Antares-CPPM 100 Mbit/sec 30,000 Euro/year Similar situation with Modane (LSM) 26

27 Networking : Renater Plan for 2014 Connect Antares/Km3Net (IMP) directly to RENATER network 1GBit/sec Investment –50,000 Euro Yearly gain –30,000 Euro 27

28 GPU So far not supported at CC-Lyon No plan to install farm with GPUs Test GPUs are available We are invited to formulate a clear request Important for KM3Net simulations !! 28

29 END 29

30 Plan L’accès aux services de BDDs L’architecture des services Configuration des clients Infrastructure Sauvegarde Bilan 2013 Planning 2014 30

31 L’accès aux services de BDDs 31 IP virtuelle Oracle MyAppService = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = myserver)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = myservice) ) Oracle/Mysql/PostgreSQL Easy connect myserver:1521/myservice

32 Plan L’accès aux services de BDDs L’architecture des services Configuration des clients Infrastructure Sauvegarde Bilan 2013 Planning 2014 32

33 L’architecture des services Mysql / PostgreSQL –Mode Actif – Passif –Basculement Automatique 33 Mysql Actif Node 01 Volume Logique Volume logique PACEMAKER Node 02 ccmysql Actif Mysql Actif ccmysql Actif Shared disk ccmysql:xxxx/myservice

34 L’architecture des services PostgreSQL –Basculement Manuel –Mode Maître / Esclave 34 PgSQL Actif Volume Logique Volume logique ccpgsql Actif PgSQL Actif en Read disk ccpgsql:xxxx/myservice ccpgsql Actif PgSQL Actif Node 01Node 02

35 L’architecture des services Oracle –Mode Actif - Actif –Répartition en fonction de la charge –Basculement Automatique –Oracle Recommande un client > 10g 35 Oracle Actif ASM ccdboraXX Actif Oracle Actif CRS ccorascanxx:xxxx/myservice Shared disk Node 01Node 02

36 CRS L’architecture des services 36 ASM Oracle Inactif ccdbora05 Actif Oracle Actif ASM ccdbora01 Actif Oracle Actif CRS Shared disk Réplication Data Guard Oracle Actif PRODUCTION SECOURS

37 Plan L’accès aux services de BDDs L’architecture des services Configuration des clients Infrastructure Sauvegarde Bilan 2013 Planning 2014 37

38 Configuration des clients 38 IP virtuelle Oracle TNS MyAppService = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = myserver)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = myservice) ) Oracle/Mysql/PostgreSQL Easy connect myserver:1521/myservice -> Le client est connecté au serveur, il émet une requête mais le serveur est en panne. Le client recevra un TCP timeout au bout de 2 heures (valeur par défaut sous linux) Adapter la configuration TCP suivant vos besoins. -> Capturer les erreurs de connexion dans votre code pour réinitialiser le processus de reconnexion

39 CRS Configuration des clients 39 ASM Oracle Actif ccdbora05 Actif Oracle Actif ASM ccdbora01 Actif Oracle Actif CRS Shared disk Oracle Data Guard Oracle Easy connect myserver:1521/myservice

40 TNS : Transparent Network Substrate (DESCRIPTION_LIST= (LOAD_BALANCE=off) (FAILOVER=on) (DESCRIPTION= (ENABLE=BROKEN) (CONNECT_TIMEOUT=5)(RETRY_COUNT=3) (ADDRESS_LIST= (LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=TCP)(HOST=myprodserver.in2p3.fr)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=myservice.in2p3.fr)) ) (DESCRIPTION= (ENABLE=BROKEN) (CONNECT_TIMEOUT=5) (RETRY_COUNT=3) (ADDRESS_LIST= (LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=TCP)(HOST=mystdbyserver.in2p3.fr)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=myservice.in2p3.fr) ) Configuration des clients 40

41 Configuration des clients Capturer les erreurs de connexion dans votre code pour réinitialiser le processus de reconnexion Toutes nos base de données destinées à la production sont sous Data Guard Centraliser les chaînes de connexion le plus possible Configuration des paramétres TCP suivant vos besoins de disponibilité L’usage des librairies 11g est fortement recommandé 41

42 Plan L’accès aux services de BDDs L’architecture des services Configuration des clients Infrastructure Sauvegarde Opérations de Maintenance Planning 2014 42

43 Plan L’accès aux services de BDDs L’architecture des services Configuration des clients Infrastructure Sauvegarde Opérations de Maintenance Planning 2014 43

44 Sauvegarde Mysql –Sauvegarde complète avec journaux de transactions –Période : Toutes les nuits –Méthode : Mysqldump ( SQL format) –Destination : sur disque et bande –Rétention : 180 jours –Sauvegarde des journaux de transactions –Période : Toutes les 6 heures –Destination : bande –Rétention : 180 jours 44

45 Sauvegarde PostgreSQL –Sauvegarde complète avec journaux de transactions –Période : Toutes les nuits –Méthode : pgdump (SQL format) + pgbackup –Destination : bande + disque –Rétention : 180 jours –Sauvegarde des journaux transactions –Période : Toutes les 6 heures –Destination : bande –Rétention : 180 jours 45

46 Sauvegarde Oracle –Sauvegarde complète avec journaux de transactions –Période : Une fois par semaine –Méthode : RMAN –Destination : Bande –Rétention : 30 jours –Sauvegarde incrémentale avec journaux de transactions –Période : 6 / 7 jours –Méthode : RMAN –Destination : Bande –Rétention : 30 jours 46

47 Bon à savoir Possibilité de restaurer une base de données / un compte à un instant précis dans le passé Avant de mettre à jour, en production, votre modèle données, demandez une sauvegarde personnaliser Identification de l’auteur d’une commande ( Oracle) Possibilité de rembobiner l’exécution d’une commande DELETE / UPDATE / INSERT (Sur Oracle seulement) IMPORTANT : EN CAS D’ERREUR DE MANIPULATION RELEVEZ L’HEURE DE L’OPERATION 47

48 Plan L’accès aux services de BDDs L’architecture des services Configuration des clients Infrastructure Sauvegarde Bilan 2013 Planning 2014 48

49 Bilan 2013 Mise en place de l’infrastructure Data guard Renouvellement des machines Opera Mise à jour des 5 serveurs Mysql en 5.6 Mise à jour des 5 serveurs PostgreSQL en 9.2 Mise en place d’une infrastructure pour LSST et E-tricks OTRS : –21 incidents résolus –25 demandes traités 49

50 Planning 2014 Client Oracle sur AFS –Plateforme RHEL6 : Client Oracle disponible A PARTIR DE LA VERSION 11.2.0.3 –Contrôler que toutes vos applications fonctionnent sur les librairies 11g Oracle : Migration d’Oracle 11.2.0.3.8 vers 11.2.0.4.1 –Eventuellement migration en fin d’année en 12C –Migration via Data Guard avec arrêt de service de l’ordre de la minute –Renouvellement de 5 machines Oracle et des switches FC Remplacement de la fonctionnalité Oracle STREAMS par Golden gate 50

51 Planning 2014 Mysql : Migration vers Mariadb 5.7 PostgreSQL : Migration vers PostgreSQL 9.3 Etude d’une plateforme Galera pour MariaDB (innodb) 51

52 Planning 2014 Procédure de renouvellement des comptes –3 incidents de SQL injection –Non respect de la charte informatique Publication des identifiants de connexion sur Internet Mise à jour de la liste des responsables de compte Une notification par mail sera envoyée à chaque responsable pour confirmer le renouvellement du ou des comptes –Sans réponse les 3 premiers mois, le compte sera verrouillé –Sans réponse dans les 6 mois qui suivent le verrouillage du compte, les données seront supprimées. 52

53 53 QUESTION ? dba@cc.in2p3.fr Privilégier un contact via OTRS