I've not had as many woes with draining as Govind up in Lancaster, but
it is slow.
We don't do anything exciting - we run a dpm-drain with 4 threads in a
screen session within a "while true; do" loop. A typical 36TB server
takes the better part of a fortnight, and we try not to do more then two
at a time to avoid overloading the system (also it makes juggling the
various spaces easier).
One thing I did noticed when I started this last batch of drains is that
I had neglected putting the newest disk pools in the oldest disk pool's
shift.conf, which caused some errors.
My apologies for likely teaching you all how to suck eggs here!
Cheers,
Matt
On 16/12/15 10:52, George, Simon wrote:
> Hi,
>
> as you already know from some questions Govind posted, we are trying to
> drain some storage nodes.
>
> I'd like to give you the bigger picture and ask for advice on the best
> approach.
>
> We have to decommission 14 old storage nodes to make rack space for new
> equipment.
>
> They run SL5 with DPM 1.8.8.4.
>
> There are two time scales:
>
> 1) We need them all decommissioned by the start of March 2016.
>
> 2) We also need one available asap to test an idea we have to reuse them.
>
> With the draining problems so far I am concerned about 1, let alone 2.
>
> If we don't succeed the choice will be between losing the data, and
> accepting new hardware (i.e. paying) without racking it up and turning
> it on, neither of which are satisfactory options to me.
>
>
> So I would like to ask if you have any advice on the best strategy to
> get this going smoothly and quickly.
>
> Thanks,
>
> Simon
>
|