<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 31, 2014 at 10:48 AM, Bryan Davis <span dir="ltr"><<a href="mailto:bd808@wikimedia.org" target="_blank">bd808@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think this will mess some things up in beta (file uploads, debug<br>
logging). If having a partial outage of beta from just after a group0<br>
deploy to just before a new branch release sounds bad to any of you<br>
you may want to respond to Coren's thread on labs-l and suggest a<br>
better time (Thurs-Fri?).<br></blockquote><div><br></div><div>I think Thu/Fri would definitely be preferable. People do a ton of pre-deploy checking on beta labs early in the week. VE for sure and probably MobileFrontend would be particularly affected.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Bryan<br>
<br>
<br>
---------- Forwarded message ----------<br>
From: Marc A. Pelletier <<a href="mailto:marc@uberbox.org">marc@uberbox.org</a>><br>
Date: Wed, Dec 31, 2014 at 10:11 AM<br>
Subject: [Labs-l] Filesystem downtime to schedule<br>
To: Wikimedia Labs <<a href="mailto:labs-l@lists.wikimedia.org">labs-l@lists.wikimedia.org</a>><br>
<br>
<br>
Hello Labs,<br>
<br>
Many of you may recall that until some point late 2013, one of the<br>
features of the labs file server was that it provided time travel<br>
snapshots (you could see a consistent view of the filesystem as it<br>
existed 1h, 2h, 3h, 1d, 2d, 3d and 1 week ago).<br>
<br>
This was disabled at that time - despite being generally considered<br>
valuable - because it was suspected to be (part of) the stability<br>
problems the NFS server suffered at the time.  This turns out to not<br>
have been the case, and we could turn it back on now.<br>
<br>
Indeed, doing so is a prerequisite to the planned replication of the<br>
filesystem in the new datacenter where a redundant Labs installation<br>
is slated to be deployed[1].<br>
<br>
The issue is that turning that feature back on requires changing the<br>
way the disk space is currently allocated at a low level[2] and<br>
necessitates a fairly long period of partial downtime during which<br>
data is being copied from one part of the disk subsystem to the other.<br>
In practice, this would require the primary partitions (/home and<br>
/data/project) to be set readonly for a period on the order of a day<br>
(24-30 hours).<br>
<br>
That downtime is pretty much unavoidable eventually as it is a<br>
requirement of expanding labs and improving data resillience and<br>
reliability, but the /timing/ of that is flexible.  I wanted to "poll"<br>
labs users as to when the possibility of disruption is minimized, and<br>
give everyone plenty of time to make contingency planning and/or<br>
notify their endusers of the expected period of reduced availability.<br>
<br>
Provided there is a good consensus that the week is a better time than<br>
the weekend (I am guessing here that volunteer coders and users are<br>
more active during the weekend) then I would suggest starting the<br>
operation on Tuesday, January 13 at 18:00 UTC.  The period of downtime<br>
is expected to last until January 14, 18:00 UTC but may extend a few<br>
hours beyond that.<br>
<br>
The expected impacts are:<br>
<br>
* Starting at the beginning of the window, /home and /data/project<br>
will switch to readonly mode; any attempt to write to files to those<br>
trees will result in EROFS errors being thrown.  Reading from those<br>
filesystems will still work as expected, so would writing to other<br>
filesystems;<br>
* Read performance may degrade noticably as the disk subsystem will be<br>
loaded to capacity;<br>
* It will not be possible to manipulate the gridengine queue -<br>
specifically, starting or stopping jobs will not work; and<br>
* At the end of the window, when the operation is complete, the "old"<br>
file system will go away and be replaced by the new one - this will<br>
cause any access to files or directories that were previously opened<br>
(including working directories) on the affected filesystems to error<br>
out with ESTALE.  Reopening files by name will access the new copy<br>
identical to the one at the time the filesystems became readonly.<br>
<br>
In practice, that latter impact has the effect that most running<br>
programs will be unable to continue unless they have special handling<br>
for this situation, and most gridengine jobs will no longer be able to<br>
log output.  It may be a good idea to restart any continuous tool at<br>
that time.  All webservices that were running at the start of the<br>
maintenance window will be restarted at that time.<br>
<br>
If you have tools or other processes running that do not rely on being<br>
able to write to /data/project, they may be able to continue running<br>
during the downtime without interruption.  Jobs that only access the<br>
network (for instance, the Mediawiki API) or the databases will not<br>
likely be affected.  Because of this, no automatic or forcible restart<br>
of running (non-webservice) jobs will be made.<br>
<br>
In particular, if you have a tool whose continued operation is<br>
important, temporarily modifying it so that it works from<br>
/data/scratch may be a good workaround.<br>
<br>
Finally, in order to avoid risks of the filesystem move taking longer<br>
than expected and increasing downtime significantly, LOG FILES OVER 1G<br>
WILL BE NOT BE COPIED.  If you have critical files that are not simple<br>
log files but whose names end in .log, .err or .out then you MUST<br>
compress those files if you absolutely require them to survive the<br>
transition.  Alternately, truncating them to some size comfortably<br>
smaller than 1G will work if the file must remain uncompressed.<br>
<br>
The speed and reliability of the maintenance process depends on the<br>
total data to copy.  If you can clean up both your home and project<br>
directories of extraneous files, you'll help the process greatly.  :-)<br>
<br>
Thanks all,<br>
<br>
-- Marc<br>
<br>
_______________________________________________<br>
Labs-l mailing list<br>
<a href="mailto:Labs-l@lists.wikimedia.org">Labs-l@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/labs-l" target="_blank">https://lists.wikimedia.org/mailman/listinfo/labs-l</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Bryan Davis              Wikimedia Foundation    <<a href="mailto:bd808@wikimedia.org">bd808@wikimedia.org</a>><br>
[[m:User:BDavis_(WMF)]]  Sr Software Engineer            Boise, ID USA<br>
irc: bd808                                        v:<a href="tel:415.839.6885%20x6855" value="+14158396885">415.839.6885 x6855</a><br>
<br>
_______________________________________________<br>
QA mailing list<br>
<a href="mailto:QA@lists.wikimedia.org">QA@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/qa" target="_blank">https://lists.wikimedia.org/mailman/listinfo/qa</a><br>
</font></span></blockquote></div><br></div></div>