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.