Hi,
This is a brief input for discussion, based on feedback from
the UB (Dave, Phil, Roger) and Tony; my summary of what I have
seen so far. Leaves out actual numbers which we can discuss
later. And it's not polished or anything, just input to
the discussion.
Thanks,
--jens
1. Recommendations for T2 storage
Assumption:
* Different VOs require different CPU/storage ratios
* Different sites support different VOs (or support them in different
ratios)
* Different sites have different sizes
Recommendations:
* Sites should allocate the "obvious" (i.e. multiply the VO's
requirements with the ratio of resources allocated to it) fraction
of storage for the main VO (or main VOs) in which they are active
and allocate extra storage for the other GridPP VOs.
* Sites should keep the timescale in mind. For example, if LHCb
requires almost nothing today, but a lot next year, then that should
be taken into account (for sites supporting LHCb).
Things to ponder:
* Does each site need to provide the "obvious" ratio of CPU/storage
(Tony thinks so, AFAICT).
In NGS for example, two core sites provide extra storage, and the
other two provide extra CPU.
* Related to this, can we "pool" storage between T2s? This was
suggested earlier for (and from) ScotGrid.
* There may be a risk that a site, aiming to meet a N TB target, will
purchase cheapo disk - some VOs will need higher quality storage
also at Tier 2s (eg for databases). What is the ratio of high
quality to "volatile"? Do all sites need to provide the same ratio?
* Many sites are finding disk underused
* If sites decide their own VO slices, how can we ensure the UK meets
the experiments' targets for T2 storage (in raw TBs, not ratios)?
Is there sufficient Alice support, for example?
Other comments:
* Sites should publish the quality of service according to best
practice;
* Sites should optimise their installations according to the
recommendations from the storage group.
* HEPiX storage task force investigating prices and technologies.
2. VO allocations
Again for the main VOs only, LCG is likely to impose the requirement
that sites dedicate storage to them. So the "free" space published is
really free and cannot be taken by another VO.
There are technical reasons why this is tricky: pools or pool groups
have to be allocated exclusively to the VO, because storage middleware
does not support quotas. Not only does it reduce the flexibility of
the storage provision, it also requires physical reallocation
(partitions, or dedicated disks) to guarantee the allocation.
|