Barbara Martelli INFN - CNAF

 Present status: Tier1DB  Architecture  Functionalities  What is missing  Evolution:  DOCET Data Oriented CEntre Tool  Architecture  Functionalities  Conclusions 2

 Home-made application aimed at:  collecting information about Tier1 H/W resources like servers, storage devices, network switches, IP-controlled PDUs  Administrative information such as vendor, purchase date, assistance phone number and assistance conditions  h/w configuration information  physical location in the data center, power cabling, network cabling  s/w configuration: operating system, network configuration  Optimizing and automating management of servers:  Automatic switch port configuration  Automatic DHCP configuration  Automatic DNS configuration  Power switch on/off 3

 Application composed by:  A PostgreSQL database back-end  A PHP user interface  On Apache web server  A series of plug-in (C, bash scripts, perl scripts)  Called by the PHP interface  Access via https web interface, X.509 certificate based authentication  Check user group affiliation on LDAP for authorization  if in tier1 group -> all resources are visible/manageable  if in another group -> read-only access limited to your resources 4

5 PostgreSQL DB IP Controlled PDU Web Server DHCP ServerDNS Server Network Switch LDAP Server PHP Application On the same physical machine Kerberos Server

 Batch insertion of large amount of homogeneous hardware  In each purchase tender is required a CSV file containing MAC addresses, serial number and position  DNS automatic configuration via web interface  nsupdate  DHCP automatic configuration via web interface  dhcpd.conf file is created, dhcpd service restart, a static dhcpd.conf part is maintained  Network switch configuration  Automatic VLAN tagging via web interface, an ad-hoc user created on each managed switch  Commands change on different switches  PDU control via web interface  Panic button in case of disaster  Some trivial monitoring: ping, h/w configuration consistency check 6

7

8

 User interface quite trivial, needs an improvement  Blade server support  h/w configuration creation process need to be more flexible and general in order to support new h/w types  Virtual machines support  No way to add virtual machines information and relation between virtual and physical machines 9

 IPMI/console management  Infrastructure inventory and monitoring  hierarchical/emergency power-off management  History of h/w and s/w configurations, failures, interventions  Reliability and availability reports 10

 Classical three-tier architecture with presentation, logic and data tiers  Data-centric application: strong data consistency and manipulation logic are implemented directly in the RDBMS  Table-driven logic (i.e. behavior strongly dependent on database contents)  Stored procedure, triggers  Highly modular: possible to add plug-in written in whatever language  Main tool is Java 1.6 on Glassfish application server v2 and PostgreSQL 8.1 DB, with particular attention to SQL standard compliance  Scalability and high availability 11

CCR Workshop - Palau12 PostgreSQL DB IPMI DHCP Server DNS Server Network Switch Web Server LDAP Server Application Server Java User Interface Data Layer Logic Layer Presentation Layer Kerberos Server Custom plug-in 12

 Perugia: interesse per la fase di design e sviluppo di plug-in per integrazione monitoraggio nagios (Vella, Cefala’)  Napoli: tool di spegnimento gerarchico attualmente funzionanti ma unattended perche' lo sviluppatore se n'e' andato. Competenze IPMI, hanno vari plug-in per marche diverse di HW. (Doria)  LNF: esperienza su Java application server, eventuale integrazione DOCET/AII? (Bisegni)  Roma1:competenze sui DB. Design schema (Bulfon) , ma anche di DB  LNL: stavano discutendo di fare un tool simile, possibilita’ di partecipazione (Fantinel) 13

 Entro fine giugno: raccolta adesioni.  Per il momento hanno risposto alla call e sono stati inseriti nella mailing list:  Padova/Legnaro: Fantinel, Crescente, Gulmini  Frascati: Bisegni  Roma1: Bulfon  CNAF: Guizzunti  Napoli (ATLAS): Doria  Si tratta di espressioni di interesse e non di possibilita’ effettiva di ritagliare tempo per una partecipazione attiva  Inizio luglio: riunione per la definizione della lista dei requirement – definizione delle priorita’ 14

 Meta’ luglio: inizio sviluppo  Bozza di una prima lista di requirement  gestione inventario macchine  Con supporto blade server, twin hardware eterogeneo  Gestione macchine virtuali  configurazione automatica dei servizi sulla base delle informazioni contenute nel DB:  VLAN tagging  DNS  IPMI  DHCP  Storico interventi di assistenza  Integrazione con servizi di monitoring gia' presenti nelle sezioni: nagios? Lemon? altro? 15

 We developed a tool which has been useful to ease the management of a large number of server/devices  The h/w evolution of last years requires an upgrade and a design improvement which can be a good occasion to create a product usable by other sites  The new design is highly modular and aims to  enable the introduction of high availability and scalability solution at each layer  enable everyone to develop his own plug-in  We would like to have a tight interaction with potentially interested INFN sites in order to create a product usable also outside CNAF  Different use cases?  Already available/in use products?  Documentation available on 16

17

18