High Performance Computing Group

 View Only
  • 1.  LSF Standard edition to LSF Suite migration

    Posted Fri February 14, 2020 08:26 AM
    Hi,
    we have an LSF installation, based on LSF Standard edition, and are currently using version 10.1.x.  We have a lot of in-house tools, etc, developed based on this.
    With the re-newal of our license, we are now entitled to use LSF Suite for HPC, which seems to be different in many ways, e.g. install locations, installation packages (RPM vs tar-files), etc.   After the license change, we have lost access to download the Standard edition, and thus we are forced(?) to deploy the LSF Suite - or are we? 
    Is there anybody here, who has gone through this exercise, and can share some experiences?  Is there any solution, where we can stick to the current installation?  I am afraid that moving to the LSF Suite will generate a lot of work, adapting the setup to our needs and/or adapting our tools to the new LSF layout.
    BTW, are the RPM packages in the LSF Suite relocatable, or do we have to stick to the default install locations?
    Regards,

    ------------------------------
    Bernd Dammann
    ------------------------------

    #SpectrumComputingGroup


  • 2.  RE: LSF Standard edition to LSF Suite migration

    Posted Thu February 20, 2020 06:55 AM

    LSF Standard and the LSF Suites are two distinct product offerings with different licensing entitlements.   So yes, you only have access to the packages you have an entitlement for, and that is what you are entitled to deploy.

    The Suites use ansible and rpm's for deployment.  At present the rpm's are not relocatable, but you could select the NFS install option and symlink from old to new.



    ------------------------------
    Bill McMillan Global Offering Manager, IBM Spectrum Computing
    ------------------------------



  • 3.  RE: LSF Standard edition to LSF Suite migration

    Posted Thu February 20, 2020 08:43 AM
    The most effective migration path in my opinion involves a sideband install of the LSF Suites on different ports.  Once that install is done, you will need brief downtime of the LSF masters to move the account and event's files to their new location.  After which, you can switch the ports of the LSF Suites, you can stop the Suites LSF services, change the ports to the production ports, and then restart the LSF services everywhere.

    You should be able to perform this migration with jobs live with essentially no downtime except for that short period of time where you are moving the events files.  You will still have a number of job res processes running, and when those jobs finish, only then can you remove the previous install.  After which, the Ansible process is quite effective at performing cluster wide change control that should be non-service interrupting for applying various service packs.

    As Bill mentions, when using the NFS install with the 10.2.0.9 release, Ansible will symbolically link /opt/ibm/lsfsuite/lsf to the NFS location of your choice.  So, this very much follows the traditional deployment model which will reduce your opex costs.

    Other tools in the Suite including Elastic.com's file and metric beats, and the various GUI components are all local installs by design.

    I hope this explains things more clearly.  If you are running on Non-Standard LSF ports, you may have to eventually have some downtime as the patch process may wish to change these ports back to the defaults, but that would need to be confirmed by the development team.

    ------------------------------
    Regards,

    Larry Adams
    TheWitness (of Cacti)
    ------------------------------



  • 4.  RE: LSF Standard edition to LSF Suite migration

    Posted Mon February 24, 2020 10:07 AM
    Hi Larry, Bill,
    thanks for your replies.   That helps to get a more clear picture of our situation. 
    I am still a little confused about the new packaging, though.  In our current installation, all LSF related files are living on a NFS share, i.e. there is no local installation on any node.   There are only two files we distribute to our nodes: an LSF profile to /etc/profile.d, and a startup script into /etc/init.d.  That makes it very easy to add (and remove) nodes in the setup, and/or replacing HW for
    With the RPM packaging, it seems that we at least need to have one node, where we install the required (or all?) RPMs - or do we need to "pollute" all our nodes with LSF RPMs? 
    And what about fixes and service packs?  Are those packaged as RPMs, too?

    Regards,

    ------------------------------
    Bernd Dammann
    ------------------------------



  • 5.  RE: LSF Standard edition to LSF Suite migration

    Posted Mon February 24, 2020 11:25 AM

    It's been a long running debate on whether "system software" should be installed locally, or installed on an NFS share....and there are very strong views held by both camps.

    The Suites packaging is trying to address both.....hopefully!

    By default, it will install RPM's locally onto each node.


    The 10.2.0.9 installer has an additional option to do a NFS install - so it will put everything into an NFS share; then you can just use lsf.conf/init.d/system.d to point at the share as you currently do.

    Yes for the suite, service packs will be rpm's



    ------------------------------
    Bill McMillan Global Offering Manager, IBM Spectrum Computing
    ------------------------------