[erlang-questions] upgrade path from R14B02 to OTP 17.5
Tanguay, Luc (A584369)
Mon Jun 15 20:10:01 CEST 2015
Erlang engineer? That must be me. I developed the whole system, and still supports it.
I use OTP releases (and rebar) and Common Test to perform basic testing. The source code and documentation is kept in a Git repository.
We have 2 servers (primary and secondary/standby). I also have a spare server in my lab that I intent to use for this major upgrade (server and clients development and testing). In the lab I have VMWare. I can create snapshot before major changes and revert back easily if something goes wrong.
The system does not run 24/7. We have a maintenance window that allow us to perfrom upgrades (servers and/or clients) when no users are in the system.
I'll begin my upgrade effort by reading the READMEs.
Luc Tanguay, ing./P. Eng.
From: Fred Hebert [mailto:]
Sent: June-15-15 13:17
To: Tanguay, Luc (A584369)
Subject: Re: [erlang-questions] upgrade path from R14B02 to OTP 17.5
On 06/15, Tanguay, Luc (A584369) wrote:
>We have a Erlang/OTP distributed system running on R14B02 Windows 2008
>(32-bit). We plan to upgrade to OTP 17.5 (64-bit). The system
>involves one big server that distribute files to up to 40 smaller
>clients, three OTP applications, many TCP links between server and
>clients, a small mnesia database, many calls to erlang:open_port/2 to
>execute native Windows programs, etc.
>What is the safest upgrade path? Go straight to OTP 17.5 or something
>else. Do I have to read all READMEs from R14B03 to OTP 17.5?
Hi Luc, there's a few interesting things to consider when going for such a plan.
The idea of going through a single big jump or many smaller ones will depend on a few things:
- Do you have a single big server? If so, what's the failover/takeover
story for this one? what are the requirements for uptime?
- Do you make use of OTP releases, or is it more of an ad-hoc deployment
system? How do you go about it?
- Do you have proper testing/staging servers to try things on?
- Do you have Erlang engineers on hand to handle this, or are you in the
(sadly somewhat common) situation where nobody knows the language, but
you still have to upgrade things?
Upgrading code itself can be done easily from small to larger versions by testing it locally and reading the READMEs for incompatible changes.
All in all, though, hot code loading works on Erlang code and NIFs, but doesn't work on the VM itself. While you can move from small release to small release (and also reload most standard libraries without much of a problem with relups and whatnot), the VM itself will need to go down and back up to upgrade the runtime system.
The safest upgrade path would be to be able to boot a second well-tested VM on a new code version on the side, and progressively move out responsibilities to this one until the old one is dead. The most brutal way to do it would just be to shut down the old node and boot the new one after.
Everything else is likely going to be a gradient in between those, in my experience.
More information about the erlang-questions