3 ms·

Thanks for the write up, especially the part on relx was enlightening. I've been toying with Erlang, and have three questions I have not been able to find good

by lmb 12y ago

Thanks for the write up, especially the part on relx was enlightening. I've been toying with Erlang, and have three questions I have not been able to find good answers to. Maybe someone could elaborate? 1) How well does Erlang deal with multiple VMs on a single machine? Are there any upsides to using a single VM per machine? (So, run your own code along side a RabbitMQ instance for example, if that is even feasible.) 2) What is a good way to have run-time mutable configuration data? I was looking into Mnesia to store user / password combinations, but it seems a bit overkill. Ideally a solution that lets you add / remove config data from a running node on the fly. 3) How do you handle access control to the node, while preserving the distributed Erlang features? VPN all machines and then only listen on the private interface?

mononcqc 12y ago
1) It deals with it well. There's no issue running one or more nodes on a single host or machine. It's been done that way before SMP was made nicer a few years ago. The distribution mechanism is based on a name@host scheme so as long as the total pair is unique to a cluster, things are usually fine. Running one VM per machine has a few upsides: better resource handling (large binaries are shared on a heap rather than copied), copying within a VM is cheaper than serializing over the network, and so on. The downside is lower isolation. For this reason, people will tend to bundle a bunch of services together if they relate to the same general logical block of applications. You should definitely be able to find a way to run your Erlang code around with RabbitMQ (though that depends on their compilation process and assumptions as well). They'll keep them separate for operational purposes often: some code bases are less mature, require more ops, crash more often, and so on, or have more erratic behavior, and so isolation is welcome in these cases. 2) See http://www.erlang.org/doc/man/config.html http://www.erlang.org/doc/man/config.html, http://www.erlang.org/doc/man/app.html http://www.erlang.org/doc/man/app.html, and http://www.erlang.org/doc/apps/kernel/application.html http://www.erlang.org/doc/apps/kernel/application.html Erlang comes out of the box with a configuration mechanism, which you may or may not make mutable at your choice on a per-application basis. 3) That's one way to do it, yes. This one or equivalent ones (restricting network access, IP tables, etc.) are the most used ones as far as I know. Some mechanisms can also include running an SSH daemon on the node and only allowing people with the right credentials to connect to a node. There's one that ships with the Erlang/OTP distribution.
rubyrescue 12y ago
1. I've tended to see slightly better overall performance running multiple VMs (nodes)/server. 2. We use zookeeper and cache locally with an ETS wrapper. It's not-erlang but there are a lot of nice zookeeper tools and the ezk module for erlang is very solid. 3. we typically don't do vpn as if the vpn goes down it is a disaster. dual nics are ideal. i don't always configure that way due to limitations of the environment (non-VPC AWS, for instance). but what are you trying to control? access to the node even if you know the cookie?
- lmb 12y ago
  Thanks for the pointers. Regarding 3), access control was probably not what I was thinking about. More like, how do I use distributed Erlang without allowing everybody access to the node (even without knowing the cookie) and how do I prevent a MITM to snoop on my Erlang traffic. [1] seems to have some decent info on in, I should have researched some more. [1] http://stackoverflow.com/questions/890938/howto-encrypt-erlang-rpc-calls-and-mnesia-replication-and-other-traffic http://stackoverflow.com/questions/890938/howto-encrypt-erla...
- jlouis 12y ago
  As for 1. do test! This is not always the case.

by lmb 12y ago

mononcqc 12y ago

1) It deals with it well. There's no issue running one or more nodes on a single host or machine. It's been done that way before SMP was made nicer a few years ago. The distribution mechanism is based on a name@host scheme so as long as the total pair is unique to a cluster, things are usually fine. Running one VM per machine has a few upsides: better resource handling (large binaries are shared on a heap rather than copied), copying within a VM is cheaper than serializing over the network, and so on. The downside is lower isolation. For this reason, people will tend to bundle a bunch of services together if they relate to the same general logical block of applications. You should definitely be able to find a way to run your Erlang code around with RabbitMQ (though that depends on their compilation process and assumptions as well). They'll keep them separate for operational purposes often: some code bases are less mature, require more ops, crash more often, and so on, or have more erratic behavior, and so isolation is welcome in these cases. 2) See http://www.erlang.org/doc/man/config.html http://www.erlang.org/doc/man/config.html, http://www.erlang.org/doc/man/app.html http://www.erlang.org/doc/man/app.html, and http://www.erlang.org/doc/apps/kernel/application.html http://www.erlang.org/doc/apps/kernel/application.html Erlang comes out of the box with a configuration mechanism, which you may or may not make mutable at your choice on a per-application basis. 3) That's one way to do it, yes. This one or equivalent ones (restricting network access, IP tables, etc.) are the most used ones as far as I know. Some mechanisms can also include running an SSH daemon on the node and only allowing people with the right credentials to connect to a node. There's one that ships with the Erlang/OTP distribution.

rubyrescue 12y ago

1. I've tended to see slightly better overall performance running multiple VMs (nodes)/server. 2. We use zookeeper and cache locally with an ETS wrapper. It's not-erlang but there are a lot of nice zookeeper tools and the ezk module for erlang is very solid. 3. we typically don't do vpn as if the vpn goes down it is a disaster. dual nics are ideal. i don't always configure that way due to limitations of the environment (non-VPC AWS, for instance). but what are you trying to control? access to the node even if you know the cookie?

lmb 12y ago
Thanks for the pointers. Regarding 3), access control was probably not what I was thinking about. More like, how do I use distributed Erlang without allowing everybody access to the node (even without knowing the cookie) and how do I prevent a MITM to snoop on my Erlang traffic. [1] seems to have some decent info on in, I should have researched some more. [1] http://stackoverflow.com/questions/890938/howto-encrypt-erlang-rpc-calls-and-mnesia-replication-and-other-traffic http://stackoverflow.com/questions/890938/howto-encrypt-erla...
jlouis 12y ago
As for 1. do test! This is not always the case.