I’m a programmer. As such, it always shock me to see something that just works. That was my feeling when I managed to run Erlang’s pool module. The setup requires some attention, but after that, it’s insultingly simple.
To run an Erlang nodes pool, you need the following:
- A set of computers with the same Erlang environment installed, one of them selected to be the master node
- Naturally, all computers must also have the code they should run in Erlang’s path
- An Erlang hosts file on the master computer (a text file with a list of hosts names, usually ~/.hosts.erlang)
- All computers must have the same Erlang cookie file (usually ~/.erlang.cookie, note that the Erlang installation generates this file on its-own)
- The master computer must have RSH or SSH no-password-required access to all other computers (some net admins ban RSH, so you have to tell Erlang to use SSH instead)
- The Erlang shell on the master computer must have a name, so it will start a node
That’s it. It is trivial to arrange on top of any modern Unix-based LAN with NFS. Once done, you run this on the master computer Erlang shell:
pool:start(Name).
Et voila! You have your-own ad-hoc, load-balancing, distributed computers pool. You don’t even have to actually start all the slave nodes: Erlang will do it for you, using the hosts file and SSH. This command from the master node starts a process with this function on the least-loaded computer:
pool:pspawn(Mod, Func, Args).
I said that this is “insultingly simple” because it’s an insult to all of those oversized, complex, commercial, expensive, BPEL-for-Web-Services-on-J2EE (or .NET) application servers. We got so used to the whole “graphical editor that generates XML that geneates code that is archived with a manifest and sent to a special server” workflow. When someone suddenly comes out and says “Hey, a shell and a plain-text config file are all you need” it’s a bit of a shocker.
Keep It Simple, Stupid.
