Computer and Network Infrastructure for the LHCb RTTC Artur Barczyk CERN/PH-LBC RTTC meeting,

2CERN, Artur Barczyk, CERN/PH-LBC Background RTTC installation in 157: 2 Farms (23 nodes each) 2 Farms (23 nodes each) Data server(s) Data server(s) Data network Data network Control PCs Control PCs Control network Control network This talk covers the “low level” infrastructure, i.e. common services needed to operate a network LHCb private network (similar to the future situation in the pit) Our own domain (daq.lhcb) Our own domain (daq.lhcb) Freedom of installation and configuration Freedom of installation and configuration Addition of HW Change of network structure as needed … All services installed and maintained by LBC All services installed and maintained by LBC Starting point for future installation in the pit Starting point for future installation in the pit

3CERN, Artur Barczyk, CERN/PH-LBC The daq.lhcb domain Connection to CERN network through a single gateway All security measures concentrated in the gateway (bastion host) All RTTC traffic local to the daq.lhcb domain 157IT Gateway Control Farms Servers daq.lhcb

4CERN, Artur Barczyk, CERN/PH-LBC DNS Name lookup in the domain Name lookup in the domainNFS Shared disk access, in particular for disk-less nodes Shared disk access, in particular for disk-less nodes DHCP, TFTP All host addresses via DHCP All host addresses via DHCP Boot server for nodes Boot server for nodesNTP For time synchronisation of all hosts For time synchronisation of all hostsKerberos Authentication AuthenticationNIS Authorization Authorization Domain services Existing from switch test bed

5CERN, Artur Barczyk, CERN/PH-LBC Security Concentrated in the gateway (already in place): Firewall Firewall SSH connections only A few selected services (like e.g. NTP sourcing from ip-time) Intrusion Detection System (IDS) Intrusion Detection System (IDS) The only host visible/accessible from outside daq.lhcb The only host visible/accessible from outside daq.lhcb If needed for RTTC, we can NAT selected hosts (e.g. control PCs) No AFS logins beyond this point No AFS logins beyond this point the price to pay for flexibility Would necessitate an AFS server inside our domain (maybe for installation in the pit?) Important for performance: no firewall needed in the nodes!

6CERN, Artur Barczyk, CERN/PH-LBC Overview Gateway DNS NTP Kerberos NIS NFS daq.lhcb cern.ch

7CERN, Artur Barczyk, CERN/PH-LBC Data server Possible (NAS) implementations: 1. Single server Cheaper solution Cheaper solution Large disk space Large disk space Up to ~100 MB/s (?) Up to ~100 MB/s (?) 2. Blade server More expensive More expensive More CPU performance More CPU performance Several 100 MB/s (c.f. Vincenzo’s studies) Several 100 MB/s (c.f. Vincenzo’s studies) 3. Server farm Why not reuse our old farm? Why not reuse our old farm? There’s 46 x 40 GB = 1.8 TB disk space (unused) There’s 46 x 40 GB = 1.8 TB disk space (unused) Distributed load and disk I/O Distributed load and disk I/O Injection SW basically same as in case 1 Injection SW basically same as in case 1 SRV HEAD SRV

8CERN, Artur Barczyk, CERN/PH-LBC Data server farm Perfectly suitable for MEP based data injection MEP building in head server Fragment files stored on farm nodes Possible file system solutions: NFS NFS Parallel file system Parallel file system Local file systems, data read through socket connection Local file systems, data read through socket connection Expertise present for all 3 solutions Code running on head server same as when using a single file server Nice way to make use of the old (otherwise unused) farm nodes HEAD SRV