SE Shutdown

SE Shutdown/Reboot Procedure

The following instructions are valid for any Storage Element, and form recommended best practice for removing one from the Grid. Much of it also applies to rebooting one (i.e., graceful shutdown - close all connections first).

It's a bit handwavy at the moment because we currently only need to do it for Classic SEs, but the general principles are the same for all SEs (some of the practical stuff may not be).

Preventing new connections

The Right Thing is to stop accepting more puts, but at the moment, no implementation is able to do that. So the second best thing is to publish 0 available space.

If you want to stop both puts and gets (but without messing with ongoing transactions), it should be sufficient to take the SE out of the information system. No published endpoint, no customers.

General shutdown procedure

1. Prevent SE from accepting more files. In theory at least, it should be sufficient that it publishes free space 0.
2. For each VO, obtain a list of files "belonging to the VO" (that were written into the SE by members of the VO).
3. Tell a suitable representative of the VO (you can ticket them via GGUS, for example):
   • What the files are (filenames) - you want the SURLs.
   • How long they have to copy off what they want to keep. It's good practice to give them at least 30 days.
   • At this point, also announce the closure of your storage in 30 days (or more, site's choice) via an EGI Broadcast from the Ops Portal.
4. Wait 30 days (or whatever you told the VO reps). Tum-de-dum.
5. Stop publishing, and take it off the Grid.
   • And announce this via the Ops Portal, too.

Specifics

For each SE, you need to know how to obtain a list of files owned by the SE.

VO Contacts

• For ATLAS send the list of files to [1]. The cloud contacts will then usually generate a savannah ticket in the DDM Operations project.

Classic SE

This entry refers to an obsolete service, but is retained for information.

A Classic SE is basically a GridFTP server. So all the files are stored in well-defined directories with appropriate Unix group ownership identifying the VO. So it's an easy exercise to get the list of files belonging to each VO.