<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Ah, reading the Mnesia docs, I see how this can work. <div><br></div><div>You’ve helped clarify many things.</div><div><br></div><div>Many thanks,</div><div><br></div><div>Lloyd<br><br><div id="AppleMailSignature" dir="ltr">Sent from my iPad</div><div dir="ltr"><br>On May 14, 2019, at 8:50 PM, Chinedu Okonkwo <<a href="mailto:codmajik@gmail.com">codmajik@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="Generator" content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1840344900;
mso-list-type:hybrid;
mso-list-template-ids:-1893797768 -1 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><div class="WordSection1"><p class="MsoNormal"><span lang="EN-US">Hi Lloyd,<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p><p class="MsoNormal"><span lang="EN-US">Unless each user will directly have access to the erlang node (via remsh) or there is a compliance requirement at play, I will like to re-iterate Scott’s point. The is approach is pointless.<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p><p class="MsoNormal"><span lang="EN-US">Erlang release is portable (per OS; so a release created on Linux only contain VM for linux), like every portable software all you need is extract and run the script.<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p><p class="MsoNormal"><span lang="EN-US">But like every application you hit the same limitation, if this is a network/web app (which I assume it is), then they will each have to be configured on different ports,<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US">because multiple applications can’t listen on same port (there are some exceptions to this), you may want to jail the application into certain folders so they don’t file:read_file(‘/etc/passwd’) on you. There will also be the backup/restore systems you will have to develop, the gateway to handle routing a user to the right instance of the app or distribute a host:port url for each user, a lot of other things you will need just to make this operational. As I said earlier this approach is almost pointless.<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p><p class="MsoNormal"><span lang="EN-US">My take will be<o:p></o:p></span></p><ol style="margin-top:0cm" start="1" type="1"><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1"><span lang="EN-US">You are better off implementing this segregation in the application layer, even if there are different apps you can route the user to the said app quite easily. Segregation can be handled in the app, you can have one dets per user or one table per user in mnesia in a single vm, you will also have all the programmatic tools to handle user idleness and shutdown unused resources.<o:p></o:p></span></li></ol><p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">From your description, I think the traditional solution is also a good solution. If anything you will likely underutilize your resources.<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p><ol style="margin-top:0cm" start="2" type="1"><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1"><span lang="EN-US">If necessary, just use a container then workout the infrastructure to route the requests, this will need some service discovery or a manual management of the route map (eg: nginx config). But the benefit of using this instead of a raw deployment is that a lot of the issues listed have solutions that have been tested.<o:p></o:p></span></li></ol><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p><div style="mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal" style="border:none;padding:0cm"><b><span lang="en-GH">From: </span></b><span lang="en-GH"><a href="mailto:lloyd@writersglen.com">Lloyd R. Prentice</a><br><b>Sent: </b>Tuesday, 14 May 2019 11:59 PM<br><b>To: </b><a href="mailto:codmajik@gmail.com">Chinedu Okonkwo</a><br><b>Cc: </b><a href="mailto:erlang-questions@erlang.org">Erlang Questions</a><br><b>Subject: </b>Re: [erlang-questions] Multiple BEAM nodes on one Linux node — a thought experiment<o:p></o:p></span></p></div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p><p class="MsoNormal"><span lang="en-GH">Hi Chinedu,<o:p></o:p></span></p><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">So operationally, would one install a release for each user in separate directories?<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">My musings, uninformed by experience, have progressed more or less along this line:<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— Data loss is totally unacceptable to the users I have in mind.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— There could be many users, each with his/her own corpus of data; no intersection.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— Traffic per user would be quite low. <o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— Data corpus per user would be fairly small. <o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— Users come and go. When they go, they want to take their data. Some may want to return and pickup where they left off.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— The traditional solution would be a capacious, maybe even distributed, database behind a single, well maybe load balanced, front end. <o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— But this means that there could potentially be an increasing volume of “dead,” e.g. unused data, or one would need a way to archive data when a user leaves. In this second case, archiving and restoring data over many users could tie up a great deal of db’s bandwidth.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— Fanciful solution I: Give each user his/her own independent website. <o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— Linux containers might make this possible.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— Transactions are not an issue.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— A small Mnesia db or even dets db per user would suffice.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— Linux containers could be deployed over multiple hardware or VPS nodes, lowering hardware failure risk and making it relatively easy to scale from just a few users to many many.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— LXD provides tools that would make it relatively easy to induct new users and replicate user sites.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— But would it be economically feasible?<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— Fanciful solution II: Multiple BEAM nodes per Linux node.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— Hmmm... might have to functionally replicate tools that LXD already provides.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— But it might be more resource efficient.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">— Can it even work?<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">And so, my head spins for lack of experience.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">And so, I’d much appreciate insight and guidance from experienced hands.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">All the best,<o:p></o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">Lloyd<o:p></o:p></span></p></div><div><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p><div id="AppleMailSignature"><p class="MsoNormal"><span lang="en-GH">Sent from my iPad<o:p></o:p></span></p></div><div><p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="en-GH"><br>On May 14, 2019, at 5:36 PM, Chinedu Okonkwo <<a href="mailto:codmajik@gmail.com">codmajik@gmail.com</a>> wrote:<o:p></o:p></span></p></div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><div><p class="MsoNormal"><span lang="en-GH">That is pretty much what erlang release is.<o:p></o:p></span></p><div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span lang="en-GH">I think its one of the reason docker/containers didn't catch on in the erlang community. The major problem you may face running it especially in distributed erlang mode may be name collusion in empd<o:p></o:p></span></p></div></div><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p><div><div><p class="MsoNormal"><span lang="en-GH">On Tue, May 14, 2019 at 9:13 PM Lloyd R. Prentice <<a href="mailto:lloyd@writersglen.com" target="_blank">lloyd@writersglen.com</a>> wrote:<o:p></o:p></span></p></div></div></div></blockquote></div></div><p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:36.0pt;margin-bottom:5.0pt;margin-left:40.8pt"><span lang="en-GH">Hello,<br><br>My Mickey-the-Dunce ignorance and curiosity has led me to explore Linux containers. Very cool. Then, a recent conversation with Oliver Korpilla tweaked my wonder nerve:<br><br>Is it possible/practical to run multiple BEAM nodes on a single Linux node?<br><br>Assume each BEAM node supports an identical web application with a Mnesia backend serving a set of CRUD services— each for a different client.<br><br>Has anyone ever done anything along this line?<br><br>Best wishes,<br><br>LRP<br><br>Sent from my iPad<br>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><o:p></o:p></span></p><p class="MsoNormal"><span lang="en-GH"><o:p> </o:p></span></p></div></div></blockquote></div></body></html>