[DRBD-user] Upgrade path for drbd?

Lars Ellenberg lars.ellenberg at linbit.com
Tue Jun 19 00:44:09 CEST 2007

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

On Tue, Jun 19, 2007 at 12:18:30AM +0200, Jan Kasprzak wrote:
> Lars Ellenberg wrote:
> : On Mon, Jun 18, 2007 at 06:39:45PM +0200, Jan Kasprzak wrote:
> : > What is the recommended procedure for upgrading drbd without the interruption
> : > of the H-A cluster?
> : 
> : yes, provided the "wire protocol version" is compatible.
> : we promise that we keep it compatible within a stable release
> : (e.g. 0.7.x or 8.0.y).
> : we may (and did) break it several times during developement cycles.
> : 
> : you are trying to upgrade from a 12 month old pre-release.
> : sorry, there have been incompatible changes in the wire protocol.
> : 
> : so no, you have a (short: stopping/umount/unload/replace/load/mount/start) downtime.
> 	OK, understood. A forward compatibility for upgrades would be nice,
> though.
> : downtime should not hurt you, anyways,
> : since, running a pre-release,
> : that server cannot possibly be
> : a production server,
> : right?
> :  :->
> 	A bad joke, really :-(, especially when (if I understand your mail
> correctly) the situation is same for 0.7.x -> 8.0.x upgrades as well. So
> even a stable->stable upgrade needs downtime.

sorry...  and thank you for trusting drbd that much!
you probably should be more conservative when doing HA deployments.

actually, we have the basic provisions in place, so in principle it
would be doable to implement such an upgrade path.

for 0.7 -> 8.0, we had no paying customer to sponsor the additional
development effort this would have introduced.

and since a well planned upgrade should not take more downtime than
necessary to shut down all services,
umount, unload, replace and load the drbd module,
then start all services backup,
this is in the order of some seconds to a couple of minutes,
depending on services actually run.

most HA deployments are exceptionally conservative, so especially for
those which services need a "long" time to stop/start, we expect them to
stick with an once established version for as long as possible,
eventually do maintenance/bug-fix updates, but no version upgrades.

unless they really need the new features, in which case they would
probably do thourough testing with an all new test stage cluster.
which then would replace the previous production cluster during a
regular scheduled maintenance window.

major decrease of development time for "boring" features
versus "minor" inconvenience for "some" users seemd to be
an acceptable tradeoff...

for future stable -> stable transitions (8.0 -> whatever we name the
next _stable_ version), there probably will be such a rolling upgrade
path, though. it may be necessary to introduce some intermediate version
talking both protocol dialects. but if enough "pressure" is applied,
which I expect will build up until we are ready to launch the next major
stable release, we will fill in the missing functionality in the already
prepared stubs.

> 	Yes, I ran the cluster on 8.0pre for more than a year with several
> successful failovers (one cluster node had a faulty mainboard, so there
> were failovers from time to time).

good to hear that it indeed did not hurt you,
but even saved you some trouble :)

: Lars Ellenberg                            Tel +43-1-8178292-0  :
: LINBIT Information Technologies GmbH      Fax +43-1-8178292-82 :
: Vivenotgasse 48, A-1120 Vienna/Europe    http://www.linbit.com :
please use the "List-Reply" function of your email client.

More information about the drbd-user mailing list