WARNING: This is the _old_ Lustre wiki, and it is in the process of being retired. The information found here is all likely to be out of date. Please search the new wiki for more up to date information.

Upgrading to a New Version of Lustre: Difference between revisions

From Obsolete Lustre Wiki
Jump to navigationJump to search
 
(73 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This section provides information about supported upgrades, upgrade paths, and interoperability of nodes with different versions of Lustre installed. It also describes procedures for upgrading your Lustre file system to a new version of Lustre. For information about available releases, see [[Lustre Release Information]].
<small>''(Updated: Dec 2009)''</small>


__TOC__
This section provides information about supported upgrades, upgrade paths, and interoperability of nodes with different versions of Lustre™ installed. It also describes procedures for upgrading your Lustre file system to a new version of Lustre. For information about available releases, see [[Lustre_Release_Information|Lustre Release Information]].


== Supported Upgrades ==
== Supported Upgrades ==


For Lustre 1.8.x, the following upgrades are supported:
For Lustre 1.8.x, the following upgrades are supported:
* Lustre 1.6.x to Lustre 1.8.0.
* Lustre 1.6.x (latest version) to Lustre 1.8.x (latest version).
* One minor version to the next (for example, 1.8.0 > 1.8.x). [[Should this say 1.8.0 > 1.8.1?]] [[Or is it OK to skip over a minor release?]]
* Lustre 1.8.x (any minor version) to Lustre 1.8.x (latest version).


For Lustre 1.8.0, if you have upgraded from an earlier version, you can downgrade to that version [[or any version in between?]]. For example:
=== Lustre Component Interoperability ===
* If you upgrade from Lustre 1.6.x > 1.8.0, you can downgrade to version 1.6.x. [[Can 1.6.x be any version of 1.6?]]
* If you upgrade from one minor version to the next (for example Lustre 1.8.0 > 1.8.x), you can downgrade to an earlier minor version (e.g., version 1.8.x). [[Should this say ...?]] If you upgrade from one minor version to the next (for example, Lustre 1.8.0.1 > 1.8.1), you can downgrade to an earlier minor version (e.g., version 1.8.0.1 or 1.8.0).


To downgrade from 1.8.x to 1.6.x, see [[#More_Information|More Information]].
Lustre interoperability enables 1.8.x servers ("new" servers) to work with 1.6.x clients ("old" clients), 1.6.x servers ("old" servers) to work with 1.8.x clients ("new" clients), and "mixed" environments with both 1.6.x and 1.8.x servers. For
example, half of each OSS failover pair could be upgraded to enable a quick reversion to 1.6 by powering down the 1.8 servers.


'''''Caution:''''' A new installation of Lustre 1.8.x is not guaranteed to be downgradeable to an earlier Lustre version [[Does this mean you may not be able to downgrade to 1.8.0 or does it mean you may not be able to downgrade to a 1.6.x version?).]]
The table below describes the interoperability between clients, OSTs, and MDTs with different versions of Lustre installed.


'''''Note:''''' If you are upgrading from Lustre 1.4.6 or later to Lustre 1.6, see [[Upgrade_to_1.6|Upgrading from 1.4.6 and later to 1.6]]
{| border="1" cellspacing=0 cellpadding="10"
! Lustre Component !! Interoperability with Other Lustre Components
|-
| rowspan="1" valign="top" | Clients
| &#149; Old, live clients can communicate with old, new, or a mix of servers.<br>&#149; Old clients can start up using old, new, or a mix of servers.<br>&#149; New clients can start up using old, new, or a mix of servers.<br>'''''Note:''''' Old clients cannot mount a file system that was created by a new MDT.
|-
| rowspan="1" valign="top" | OSTs
| &#149; Old OSTs can communicate with new clients/MDTs.<br>&#149; New OSTs can only be started after the MGS has been started (typically after the MDT has been upgraded).
|-
| rowspan="1" valign="top" | MDTs
| &#149; An old MDT can communicate with new clients.<br>&#149; A new co-located MGS/MDT can be started at any point.<br>&#149; A new non-co-located MDT can be started after the MGS starts.
|}


=== Supported Upgrade Paths ===  
== Upgrading Lustre 1.6.x to Lustre 1.8.x ==
Two Lustre upgrade paths are supported. Either can be applied to the entire file system or a combination of the two can be used to upgrade individual servers and clients.
Two Lustre upgrade paths are supported to meet the upgrade requirements of different Lustre environments.


* ''Rolling upgrade'' - Individual servers (or their failover partners) and clients are upgraded one at a time and restarted, so that the file system never goes down. This type of upgrade limits the ability to change certain parameters.
* ''Entire file system upgrade'' - All servers and clients are shut down and upgraded at the same time. See [[#Performing a Complete File System Upgrade|Performing a Complete File System Upgrade]].
* ''Entire file system upgrade'' - All servers and clients are shut down and upgraded at the same time.
* ''Rolling upgrade'' - Individual servers (or their failover partners) and clients are upgraded one at a time and restarted, so that the file system never goes down. See [[#Performing a Rolling Upgrade|Performing a Rolling Upgrade]].


=== Interoperability between Nodes with Different Versions of Lustre Installed ===
'''''Note:''''' If you upgrade some Lustre components to 1.8.x but not others (such as running 1.8 clients in a file system with 1.6 OSTs), and run a mixed environment, you may see one or more warnings similar to this:


Interoperability between clients, OSTs, and MDTs with different versions of Lustre installed is described below.
<pre>
LustreError: 3877:0:(socklnd_cb.c:2228:ksocknal_recv_hello())
Unknown protocol version (2.x expected) from 192.168.2.43
</pre>


[[Does "old" mean a node with any older version of Lustre installed or just 1.6.x?]]
This warning is given when the 1.6 and 1.8 components use different protocols. It
can be safely ignored because the Lustre components negotiate a common protocol.
In this example, the 1.8 clients fall back to use the 1.6 protocol with the 1.6 OSTs.


[[Does "new" mean specifically 1.8.x??]]
=== Performing a Complete File System Upgrade ===
This procedure describes a complete file system upgrade in which 1.8.x Lustre packages are installed on multiple 1.6.x servers and clients, requiring a file system shut down. If you want to upgrade one Lustre component at a time and avoid the shutdown, see [[#Performing a Rolling Upgrade|Performing a Rolling Upgrade]].


[[Does "mixed" mean a group of servers, some with older versions of Lustre and some with newer versions of Lustre installed?]]
'''''Tip:''''' In a Lustre upgrade, the package install and file system unmount steps are reversible; you can do either step first. To minimize downtime, this procedure first performs the 1.8.x package installation, and then unmounts the file system.


''Clients''
1. ''Make a complete, restorable file system backup before upgrading Lustre.''
* Old live clients can continue to communicate with [[old/new/mixed]] servers.
* Old clients can start up using old/new/mixed servers.
* New clients can start up using old/new/mixed servers (use old mount format for
old MDT).


''OSTs''
2. ''Install the 1.8.x packages on the Lustre servers and/or clients.'' Some or all servers can be upgraded. Some or all clients can be upgraded. For help determining where to install a specific package, see [[Lustre Packages]].
* New clients/MDTs can continue to communicate with old OSTs.
* New OSTs can only be started after the MGS has been started (typically this
means "after the MDT has been upgraded.")


''MDTs''
:a. ''Install the kernel, modules and ldiskfs packages.'' For example:
* New clients can communicate with old MDTs.
* New co-located MGS/MDTs can be started at any point.
* New non-MGS MDTs can be started after the MGS starts.


:<pre>
;$ rpm -ivh
;kernel-lustre-smp-<ver> \
;kernel-ib-<ver> \
;lustre-modules-<ver> \
;lustre-ldiskfs-<ver>
</pre>


:b. ''Upgrade the utilities/userspace packages.'' For example:


Interoperability limitations:
:<pre>
;$ rpm -Uvh lustre-<ver>
</pre>


* Old clients cannot mount a file system which was created by a new MDT.
:c. ''If a new e2fsprogs package is available, upgrade it.'' For example:


* If your file system was originally created using Lustre 1.8.x, you will not be able to mount '''the''' '''[[(a?)]]''' file system created using an earlier Lustre version. However, if your system has been upgraded from 1.6.x to 1.8.x, you can mount Lustre clients on both Lustre versions. Lustre 1.8.x clients are interoperable with 1.6.x servers.
:<pre>
;$ rpm -Uvh e2fsprogs-<ver>
</pre>


:There may or may not be a new ''e2fsprogs'' package with a Lustre upgrade. The ''e2fsprogs'' release schedule is independent of Lustre releases.


[[Find a place for this note]]
:d. (Optional) ''If you want to add optional packages to your Lustre system, install them now.''
'''''Note:''''' In Lustre version 1.6 and later, the file system name (''--fsname parameter'') is limited to 8 characters so that it fits on the disk label.


== Prerequisites to Upgrading Lustre==
3. ''Shut down the file system.'' Shut down the components in this order: clients, then the MDT, then OSTs. Unmounting a block device causes Lustre to be shut down on that node.


This content was in the OM section "Upgrading from Lustre 1.6.x to Lustre 1.8.0"
:a. Unmount the clients. On each client node, run:


[[What are these procedures? Do they need to be completed before the upgrade is started?]]
:<pre>
;umount <mount point>
</pre>


Remember the following points before upgrading Lustre.
:b. Unmount the MDT. On the MDS node, run:


''The MDT must be upgraded before the OSTs are upgraded.'' [[summarize steps in a sentence]]
:<pre>
;umount <mount point>
</pre>


1. Shut down lconf failover.
:c. Unmount the OSTs (be sure to unmount all OSTs). On each OSS node, run:


2. Install the new modules.
:<pre>
;umount <mount point>
</pre>


3. Run tunefs.lustre.
4. ''Unload the old Lustre modules'' by either:
* Rebooting the node
:- OR -
* Removing the Lustre modules manually. Run ''lustre_rmmod'' several times and use ''lsmod'' to check the currently loaded modules.
 
5. ''Start the upgraded file system.'' Start the components in this order: OSTs, then the MDT, then clients.
:a. ''Mount the OSTs'' (be sure to mount all OSTs). On each OSS node, run:
 
:<pre>
;mount -t lustre <block device name> <mount point>
</pre>


4. Mount startup.
:b. ''Mount the MDT.'' On the MDS node, run:


''A Lustre upgrade can be done across a failover pair.'' - [[In a failover pair, do the backup server first]]
:<pre>
;mount -t lustre <block device name> <mount point>
</pre>


1. On the backup server, install the new modules.
:c. ''Mount the file system on the clients.'' On each client node, run:


2. Shut down lconf failover.
:<pre>
;mount -t lustre <MGS node>&#58;/<fsname> <mount point>
</pre>


3. On the new server, run tunefs.lustre.
If you have a problem upgrading Lustre, contact us by [[Reporting Bugs|submitting a bug]] to our bug tracker [https://bugzilla.lustre.org/query.cgi Bugzilla].


4. On the new server, mount startup.
=== Performing a Rolling Upgrade ===
This procedure describes a rolling upgrade in which one Lustre component (server or client) is upgraded and restarted at a time while the file system is running. If you want to upgrade the complete Lustre file system or multiple components at a time, requiring a file system shutdown, see [[#Performing a Complete File System Upgrade|Performing a Complete File System Upgrade]].


5. On the primary server, install the new modules.
----


== Upgrade procedures ==
'''''Note:''''' If the Lustre component to be upgraded is an OSS in a failover pair, follow these special upgrade steps to minimize downtime:


=== Upgrading Clients ===
1. ''Fail over the server to its peer server'', so the file system remains available.


* Starting Clients - [[if upgraded client only would need to know how to start a new client with an old MDT - says use old command - relevant depending on which machines you start with  - if you start with clients you need to know this information. ]][[Need instructions on upgrading a client]][[see initial client install ch 3 - intermingled - discuss with Sheila - something missing]]
2. ''Install the Lustre 1.8.x packages on the idle server.''


You can start a new client with an old MDT by using the old format of the client
3. ''Unload the old Lustre modules on the idle server'' by either:
mount command:
:* Rebooting the node.
:- OR -
:* Removing the Lustre modules manually by running the ''lustre_rmmod'' command several times and checking the currently loaded modules with the ''lsmod'' command.


client# mount -t lustre <mdtnid>:/<mdtname>/client <mountpoint>
4. ''Fail back services to the now upgraded server.''


You can start a new client with an upgraded MDT by using the new format and
5. ''Repeat Steps 1 to 4 on the peer server.'' This limits the outage (per OSS) to a single server for as long as it takes to fail over.
pointing it at the MGS, not the MDT (for co-located MDT/MGS, this is the same):


client# mount -t lustre <mgsnid>:/<fsname> <mountpoint>
----
To perform a rolling upgrade:


Old clients always use the old format of the mount command, regardless of whether
1. ''Make a complete, restorable file system backup before upgrading Lustre.''
the MDT has been upgraded or not.


=== Upgrading a Single File System ===
2. ''Install the 1.8.x packages on the Lustre component (server or client).'' For help determining where to install a specific package, see [[Lustre Packages]].


tunefs.lustre will find the old client log on an 1.4.x MDT that is being upgraded
:a. ''Install the kernel, modules and ''ldiskfs'' packages.'' For example:
to 1.6. (If the name of the client log is not "client", use the lustre_up14.sh script,
described in Step 2 and Step 3.)


1. Shut down the MDT.
:<pre>
;$ rpm -ivh
;kernel-lustre-smp-<ver> \
;kernel-ib-<ver> \
;lustre-modules-<ver> \
;lustre-ldiskfs-<ver>
</pre>


mdt1# lconf --failover --cleanup config.xml
:b. ''Upgrade the utilities/userspace packages.'' For example:


2. Install the new Lustre version and run tunefs.lustre to upgrade the
:<pre>
configuration.
;$ rpm -Uvh lustre-<ver>
</pre>


There are two options:
:c. ''If a new ''e2fsprogs'' package is available, upgrade it.'' For example:


* Rolling upgrade keeps a copy of the original configuration log, allowing immediate reintegration into a live file system, but prevents OSC parameter and failover NID changes. (The writeconf procedure can be performed later to eliminate these restrictions. For details, see [[Running the Writeconf Command]].)
:<pre>
;$ rpm -Uvh e2fsprogs-<ver>
</pre>


mdt1# tunefs.lustre --mgs --mdt --fsname=testfs /dev/sda1
There may or may not be a new ''e2fsprogs'' package with a Lustre upgrade. The ''e2fsprogs'' release schedule is independent of Lustre releases.


* ''i.--writeconf'' begins a new configuration log, allowing permanent modification of all parameters (see Changing Parameters), but requiring all other servers and clients to be stopped at this point. No clients can be started until all OSTs are upgraded.
:d. (''Optional) If you want to add optional packages to your Lustre system, install them now.''


<pre>
3. ''Unload the old Lustre modules'' by either:
[root@mds1]# tunefs.lustre --mgs --writeconf --mgs --mdt --
:* Rebooting the node
fsname=ldiskfs /dev/hda4
:- OR -
checking for existing Lustre data: found CONFIGS/mountdata
:* Removing the Lustre modules manually. Run ''lustre_rmmod'' several times and use ''lsmod'' to check the currently-loaded modules.
Reading CONFIGS/mountdata
Read previous values:
Target: testfs-MDT0000
Index: 0
UUID: mds-1_UUID
Lustre FS: testfs
Mount type: ldiskfs
Flags: 0x205
(MDT MGS upgrade1.4 )
Persistent mount opts: errors=remount-ro,iopen_nopriv,user_xattr
Parameters:
Permanent disk data:
Target: ldiskfs-MDT0000
Index: 0
UUID: mds-1_UUID
Lustre FS: ldiskfs
Mount type: ldiskfs
Flags: 0x305
(MDT MGS writeconf upgrade1.4 )
Persistent mount opts: errors=remount-ro,iopen_nopriv,user_xattr
Parameters:
Writing CONFIGS/mountdata
Copying old logs
</pre>


3. Start the upgraded MDT.
4. ''If the upgraded component is a server, fail back services to the new server.''


<pre>
If you have a problem upgrading Lustre, contact us via the [https://bugzilla.lustre.org/query.cgi Bugzilla] bug tracker.
mdt1# mkdir -p /mnt/test/mdt
mdt1# mount -t lustre /dev/hda4 /mnt/test/mdt
mdt1 # df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda2 10080520 4600820 4967632 49% /
/dev/hda1 101086 14787 81080 16% /boot
none 501000 0 501000 0% /dev/shm
/dev/hda4 23339176 455236 21550144 3% /mnt/test/mdt
</pre>


4. Upgrade and start the OSTs for the file system in a similar manner, except they need the address of the MGS. Old installations may also need to specify the OST index (for instance, ''--index=5'').
== Upgrading Lustre 1.8.x to the Next Minor Version ==


<pre>
To upgrade Lustre 1.8.x to the next minor version, for example, Lustre 1.8.0.1 > 1.8.x,
ost1# tunefs.lustre --ost --fsname=lustre --mgsnode=mds /dev/sda4
follow these procedures:
checking for existing Lustre data: found last_rcvd
* To upgrade the complete file system or multiple file system components at the same time, requiring a file system shutdown, see [[#Performing_a_Complete_File_System_Upgrade|Performing a Complete File System Upgrade]]
tunefs.lustre: Unable to read /tmp/dirQi2cwV/mountdata (No such
* To upgrade one Lustre component (server or client) at a time, while the file system is running, see [[#Performing_a_Rolling_Upgrade|Performing a Rolling Upgrade]]
file or directory.)
Trying last_rcvd
Reading last_rcvd
Feature compat=2, incompat=0
Read previous values:
Target:
Index: 0
UUID: ost1_UUID
Lustre FS: lustre
Mount type: ldiskfs
Flags: 0x202
(OST upgrade1.4 )
Persistent mount opts:
Parameters:
Permanent disk data:
Target: lustre-OST0000
Index: 0
UUID: ost1_UUID
Lustre FS: lustre
Mount type:ldiskfs
Flags: 0x202
(OST upgrade1.4 )
Persistent mount opts: errors=remount-ro,extents,mballoc
Parameters: mgsnode=192.168.10.34@tcp
Writing CONFIGS/mountdata 11.1.5 Upgrading Multiple File Systems
with a Shared MGS
Ost-1# mount -t lustre /dev/sda4 /mnt/test/ost/
Ost1# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 10080520 3852036 5716416 41% /
/dev/sda1 101086 14964 80903 16% /boot
none 501000 0 501000 0% /dev/shm
/dev/sda4 101492248 471672 95781780 1% /mnt/test/ost
</pre>


=== Upgrading to the Next Minor Version ===
== Downgrading from Lustre 1.8.x ==
For Lustre 1.8.x, the following downgrades are supported:
* If you upgraded from Lustre 1.6.x > 1.8.x, you can downgrade to version 1.6.x.
* If you upgraded from one minor version to the next (for example, Lustre 1.8.0 > 1.8.x), you can downgrade to the earlier minor version.


Upgrading Lustre 1.8.0 to the Next Minor Version [[X]]
For a procedure to downgrade from Lustre 1.8.x to Lustre 1.6.x, see [http://wiki.lustre.org/manual/LustreManual18_HTML/UpgradingLustre.html#50651255_38760 Section 13.5: ''Downgrading from Lustre 1.8.x to Lustre 1.6.x''] in the [http://wiki.lustre.org/manual/LustreManual18_HTML/index.html ''Lustre Operations Manual''].


== More Information ==
'''''Caution:''''' A new installation of Lustre 1.8.x is not guaranteed to be downgradable to an earlier Lustre version.
See the [[Lustre_Documentation|''Lustre Operations Manual'']] for information about:
* Upgrading Multiple File Systems with a Shared MGS
* Downgrading from Lustre 1.8.0 to Lustre 1.6.x

Latest revision as of 10:23, 20 January 2011

(Updated: Dec 2009)

This section provides information about supported upgrades, upgrade paths, and interoperability of nodes with different versions of Lustre™ installed. It also describes procedures for upgrading your Lustre file system to a new version of Lustre. For information about available releases, see Lustre Release Information.

Supported Upgrades

For Lustre 1.8.x, the following upgrades are supported:

  • Lustre 1.6.x (latest version) to Lustre 1.8.x (latest version).
  • Lustre 1.8.x (any minor version) to Lustre 1.8.x (latest version).

Lustre Component Interoperability

Lustre interoperability enables 1.8.x servers ("new" servers) to work with 1.6.x clients ("old" clients), 1.6.x servers ("old" servers) to work with 1.8.x clients ("new" clients), and "mixed" environments with both 1.6.x and 1.8.x servers. For example, half of each OSS failover pair could be upgraded to enable a quick reversion to 1.6 by powering down the 1.8 servers.

The table below describes the interoperability between clients, OSTs, and MDTs with different versions of Lustre installed.

Lustre Component Interoperability with Other Lustre Components
Clients &#149; Old, live clients can communicate with old, new, or a mix of servers.
&#149; Old clients can start up using old, new, or a mix of servers.
&#149; New clients can start up using old, new, or a mix of servers.
Note: Old clients cannot mount a file system that was created by a new MDT.
OSTs &#149; Old OSTs can communicate with new clients/MDTs.
&#149; New OSTs can only be started after the MGS has been started (typically after the MDT has been upgraded).
MDTs &#149; An old MDT can communicate with new clients.
&#149; A new co-located MGS/MDT can be started at any point.
&#149; A new non-co-located MDT can be started after the MGS starts.

Upgrading Lustre 1.6.x to Lustre 1.8.x

Two Lustre upgrade paths are supported to meet the upgrade requirements of different Lustre environments.

Note: If you upgrade some Lustre components to 1.8.x but not others (such as running 1.8 clients in a file system with 1.6 OSTs), and run a mixed environment, you may see one or more warnings similar to this: 

LustreError: 3877:0:(socklnd_cb.c:2228:ksocknal_recv_hello())
Unknown protocol version (2.x expected) from 192.168.2.43

This warning is given when the 1.6 and 1.8 components use different protocols. It can be safely ignored because the Lustre components negotiate a common protocol. In this example, the 1.8 clients fall back to use the 1.6 protocol with the 1.6 OSTs.

Performing a Complete File System Upgrade

This procedure describes a complete file system upgrade in which 1.8.x Lustre packages are installed on multiple 1.6.x servers and clients, requiring a file system shut down. If you want to upgrade one Lustre component at a time and avoid the shutdown, see Performing a Rolling Upgrade.

Tip: In a Lustre upgrade, the package install and file system unmount steps are reversible; you can do either step first. To minimize downtime, this procedure first performs the 1.8.x package installation, and then unmounts the file system.

1. Make a complete, restorable file system backup before upgrading Lustre.

2. Install the 1.8.x packages on the Lustre servers and/or clients. Some or all servers can be upgraded. Some or all clients can be upgraded. For help determining where to install a specific package, see Lustre Packages.

a. Install the kernel, modules and ldiskfs packages. For example:


$ rpm -ivh


kernel-lustre-smp-<ver> \


kernel-ib-<ver> \


lustre-modules-<ver> \


lustre-ldiskfs-<ver>



b. Upgrade the utilities/userspace packages. For example:




$ rpm -Uvh lustre-<ver>



c. If a new e2fsprogs package is available, upgrade it. For example:




$ rpm -Uvh e2fsprogs-<ver>



There may or may not be a new e2fsprogs package with a Lustre upgrade. The e2fsprogs release schedule is independent of Lustre releases.


d. (Optional) If you want to add optional packages to your Lustre system, install them now.


3. Shut down the file system. Shut down the components in this order: clients, then the MDT, then OSTs. Unmounting a block device causes Lustre to be shut down on that node.



a. Unmount the clients. On each client node, run:




umount <mount point>



b. Unmount the MDT. On the MDS node, run:




umount <mount point>



c. Unmount the OSTs (be sure to unmount all OSTs). On each OSS node, run:




umount <mount point>



4. Unload the old Lustre modules by either:



  • Rebooting the node


- OR -


  • Removing the Lustre modules manually. Run lustre_rmmod several times and use lsmod to check the currently loaded modules.


5. Start the upgraded file system. Start the components in this order: OSTs, then the MDT, then clients.



a. Mount the OSTs (be sure to mount all OSTs). On each OSS node, run:




mount -t lustre <block device name> <mount point>



b. Mount the MDT. On the MDS node, run:




mount -t lustre <block device name> <mount point>



c. Mount the file system on the clients. On each client node, run:




mount -t lustre <MGS node>:/<fsname> <mount point>



If you have a problem upgrading Lustre, contact us by submitting a bug to our bug tracker Bugzilla.



Performing a Rolling Upgrade


This procedure describes a rolling upgrade in which one Lustre component (server or client) is upgraded and restarted at a time while the file system is running. If you want to upgrade the complete Lustre file system or multiple components at a time, requiring a file system shutdown, see Performing a Complete File System Upgrade.





Note: If the Lustre component to be upgraded is an OSS in a failover pair, follow these special upgrade steps to minimize downtime:

1. Fail over the server to its peer server, so the file system remains available.

2. Install the Lustre 1.8.x packages on the idle server.

3. Unload the old Lustre modules on the idle server by either:



  • Rebooting the node.


- OR -

  • Removing the Lustre modules manually by running the lustre_rmmod command several times and checking the currently loaded modules with the lsmod command.


4. Fail back services to the now upgraded server.

5. Repeat Steps 1 to 4 on the peer server. This limits the outage (per OSS) to a single server for as long as it takes to fail over.





To perform a rolling upgrade:

1. Make a complete, restorable file system backup before upgrading Lustre.

2. Install the 1.8.x packages on the Lustre component (server or client). For help determining where to install a specific package, see Lustre Packages.



a. Install the kernel, modules and ldiskfs packages. For example:




$ rpm -ivh


kernel-lustre-smp-<ver> \


kernel-ib-<ver> \


lustre-modules-<ver> \


lustre-ldiskfs-<ver>



b. Upgrade the utilities/userspace packages. For example:




$ rpm -Uvh lustre-<ver>



c. If a new e2fsprogs package is available, upgrade it. For example:




$ rpm -Uvh e2fsprogs-<ver>



There may or may not be a new e2fsprogs package with a Lustre upgrade. The e2fsprogs release schedule is independent of Lustre releases.



d. (Optional) If you want to add optional packages to your Lustre system, install them now.


3. Unload the old Lustre modules by either:



  • Rebooting the node


- OR -

  • Removing the Lustre modules manually. Run lustre_rmmod several times and use lsmod to check the currently-loaded modules.


4. If the upgraded component is a server, fail back services to the new server.

If you have a problem upgrading Lustre, contact us via the Bugzilla bug tracker.



Upgrading Lustre 1.8.x to the Next Minor Version


To upgrade Lustre 1.8.x to the next minor version, for example, Lustre 1.8.0.1 > 1.8.x,
follow these procedures:




Downgrading from Lustre 1.8.x


For Lustre 1.8.x, the following downgrades are supported:



  • If you upgraded from Lustre 1.6.x > 1.8.x, you can downgrade to version 1.6.x.
    • 

  • If you upgraded from one minor version to the next (for example, Lustre 1.8.0 > 1.8.x), you can downgrade to the earlier minor version.


For a procedure to downgrade from Lustre 1.8.x to Lustre 1.6.x, see Section 13.5: Downgrading from Lustre 1.8.x to Lustre 1.6.x in the Lustre Operations Manual.

Caution: A new installation of Lustre 1.8.x is not guaranteed to be downgradable to an earlier Lustre version.



Retrieved from "http://wiki.old.lustre.org/index.php?title=Upgrading_to_a_New_Version_of_Lustre&oldid=12219"