<div dir="ltr">What can I expect to happen to the jobs that are suspended during the file system restart?<div>Will the processes holding an open file handle die when I unsuspend them after the filesystem restart?</div><div><br></div><div>Thanks!</div><div>-Raj</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 21, 2019 at 12:52 PM Colin Faber <<a href="mailto:cfaber@gmail.com">cfaber@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Ah yes, <br></div><div><br></div><div>If you're adding to an existing OSS, then you will need to reconfigure the file system which requires writeconf event.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 21, 2019 at 10:00 AM Raj Ayyampalayam <<a href="mailto:ansraj@gmail.com" target="_blank">ansraj@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The new OST's will be added to the existing file system (the OSS nodes are already part of the filesystem), I will have to re-configure the current HA resource configuration to tell it about the 4 new OST's.<div>Our exascaler's HA monitors the individual OST and I need to re-configure the HA on the existing filesystem.</div><div><br></div><div>Our vendor support has confirmed that we would have to restart the filesystem if we want to regenerate the HA configs to include the new OST's.</div><div><br></div><div>Thanks,</div><div>-Raj<br><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 21, 2019 at 11:23 AM Colin Faber <<a href="mailto:cfaber@gmail.com" target="_blank">cfaber@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>It seems to me that steps may still be missing?</div><div><br></div><div>You're going to rack/stack and provision the OSS nodes with new OSTs'. <br></div><div><br></div><div>Then you're going to introduce failover options somewhere? new osts? existing system? etc?</div><div><br></div><div>If you're introducing failover with the new OST's and leaving the existing system in place, you should be able to accomplish this without bringing the system offline. <br></div><div><br></div><div>If you're going to be introducing failover to your existing system then you will need to reconfigure the file system to accommodate the new failover settings (failover nides, etc.)</div></div><div dir="ltr"><div><br></div><div>-cf</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 21, 2019 at 9:13 AM Raj Ayyampalayam <<a href="mailto:ansraj@gmail.com" target="_blank">ansraj@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Our upgrade strategy is as follows:<div><br></div><div>1) Load all disks into the storage array.</div><div>2) Create RAID pools and virtual disks.</div><div>3) Create lustre file system using mkfs.lustre command. (I still have to figure out all the parameters used on the existing OSTs).</div><div>4) Create mount points on all OSSs.</div><div>5) Mount the lustre OSTs.</div><div>6) Maybe rebalance the filesystem.</div><div>My understanding is that the above can be done without bringing the filesystem down. I want to create the HA configuration (corosync and pacemaker) for the new OSTs. This step requires the filesystem to be down. I want to know what would happen to the suspended processes across the cluster when I bring the filesystem down to re-generate the HA configs.</div><div><br></div><div>Thanks,</div><div>-Raj</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 21, 2019 at 12:59 AM Colin Faber <<a href="mailto:cfaber@gmail.com" target="_blank">cfaber@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Can you provide more details on your upgrade strategy? In some cases expanding your storage shouldn't impact client / job activity at all.</div><br><div class="gmail_quote"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 20, 2019, 11:09 AM Raj Ayyampalayam <<a href="mailto:ansraj@gmail.com" target="_blank">ansraj@gmail.com</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>We are planning on expanding our storage by adding more OSTs to our lustre file system. It looks like it would be easier to expand if we bring the filesystem down and perform the necessary operations. We are planning to suspend all the jobs running on the cluster. We originally planned to add new OSTs to the live filesystem.</div><div><br></div><div>We are trying to determine the potential impact to the suspended jobs if we bring down the filesystem for the upgrade.</div><div>One of the questions we have is what would happen to the suspended processes that hold an open file handle in the lustre file system when the filesystem is brought down for the upgrade?</div><div>Will they recover from the client eviction?</div><div><br></div><div>We do have vendor support and have engaged them. I wanted to ask the community and get some feedback.</div><div><br></div><div>Thanks,</div><div>-Raj</div></div></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
lustre-discuss mailing list<br>
<a href="mailto:lustre-discuss@lists.lustre.org" rel="noreferrer" target="_blank">lustre-discuss@lists.lustre.org</a><br>
<a href="http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org" rel="noreferrer noreferrer" target="_blank">http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org</a><br>
</blockquote></div>
</blockquote></div></div></div>
</blockquote></div>
</blockquote></div></div></div></div>
</blockquote></div>
</blockquote></div>