Confluence page: https://confluence.infn.it/display/CNAF/CNAF_Trilaterale+Home
Progetto JIRA: https://issues.infn.it/jira/projects/CNTRI/issues/
Spostare minute su confluence
news su redirector: storm-webdav unica implementazione che usa https anche per trasferimento, potrebbe avere redirect verso http plain. Implementato in prossima versione per GET - configurare webdav per fare redirect da https==>http, ma potrebbe anche essere https==>https che permetterebbe di avere head node storm + serie di transfer node nginx (magari aggiunti/rimossi dinamicamente)
rende possibile confronto diretto con gridftp plain vs plain
da valutare drop di performance in uso https vs http
per test:
step 0 - configurare sotrage area non autenticata e misurare differenza (non serve redirector) - usiamo endpoint di produzione, es. atlas azione:storage/SD
step 1 - confrontare con nginx con redirector - possiamo farlo su un xfer - possiamo partire da una macchina singola anche vm usando localhost
dubbi su deployment redis che ha un costo, attendiamo valutazione infinispan ma occorre verificare supporto multicast
https://ggus.eu/index.php?mode=ticket_info&ticket_id=150181
problemi visti da ATLAS risolti/capiti (differenza in bandwidth delle macchine coinvolte)
solved (StoRM) We (or I) now finally understand StoRM behavior and in the latest test we reached * webdav time to transfer 2TB (2000x 1GB) with 200 concurrent connections ... 1403s (1.42GB/s) * SRM+gsiftp time to transfer 2TB (2000x 1GB) with 200 concurrent connections ... 217s (9.22GB/s) The reason for different throughput is not related to StoRM, but WebDAV interface total capacity to the backend storage is now 4GB/s (perfectly OK for current ATLAS TPC transfers to INFN-T1 disks with monthly average ~ 400MB/s) while for GridFTP total capacity is 30GB/s. This will change once we move everything to WebDAV and than GridFTP interfaces will be converted to the WebDAV. Petr
Storm-atlas: xs-201/301/401
webdav atlas: ds-816/916
evitare che webdav consuma tutte le risorse disponibili su nsd - possiamo tunare limitando numero max di connessioni - oppure cpu consumata per https, questo lo vediamo nei hest https/http
azione: convertire 1 server gridftp in webdav e vediamo cosa succede cercando di capire a cosa è dovuto il carico xs-201==> webdav. Per adesso non cambiamo staging su cric e vediamo se la differenza di hw cambia qualcosa (xs-201) azione Storage
Storm-cms: xs-402/403
Webdav CMS: xs-404/
storm-lhcb: xs-101/102/xs-2013
webdav lhcb: xs-104
storm-ams: ds-806/906
storm-archive:ds-509/510/511/512 (I gridftp sono anche StoRM WebDAV server per Belle, Virgo e CTA-LST )
attività anche dentro pett/smartchain (Arianna?) e IoTwins (Barbara). Esistono istante già deployate?