Tutorial Step 8 - Distributing the service
In this step we will focus on distributing our service on the few Erlang nodes.
Contents
Overall architecture
At the beginning we must think about the systems' architecture. Our shop is now running on the single node - of course if we have 16 core machine it scales well - the cache is offloading the database (we do not need to fetch e.g. all of the items) but at some point we are facing the performance barrier we cannot overtake. (sometimes it is an I/O or CPU, sometimes RAM is too small). Then is a time when we make a decision to split the service into two parts: frontend and the backend.
Frontend is actually the web server + cache: it is maximally thin and stateless. Backend on the other hand holds the database and the controllers - so it is rather heavy and should be offloaded.
Because of that there could be many frontend servers and can be only one active backend (it will keep all the state). Of course we can add the additional backend for the fault tolerance reasons.
Since the frontends are stateless as much as it is possible at the beginning they do not know anything about the backends - they politely wait until one will connect to them and say: "hello, I am your backend server, from now all the backend related things should be redirected straight to me!".
Creating the two nodes
Let's start from the simplest case: one frontend and one backend server (for the convenience we will be using FE and BE acronyms for frontend and backend respectively). Let's copy the project to two directories: backend/ and frontend/.
backend configuration
At first, we must edit the project configuration file: config/project.conf:
1 {fe_servers, [fe1@erlang.local]}.
Where fe1@erlang.local is the name of our frontend node.
Then we should change lib/eptic-1.3/ebin/eptic.app node_type variable from single_node_with_cache to backend.
frontend configuration
The only change on the frontend side is the change of the eptic.app file: from single_node_with_cache to frontend.
We are now ready to roll!
Running the project
Let's start the backend firstly (assume that backend@erlang.local has been put in /etc/hosts file and is an alias for localhost):
$ ./bin/start_interactive inets backend -name backend@erlang.local
When we will see the prompt, let's initialize the database (since our node name has changed, we must create a new schema and admin account):
1 1> db_init:init().
2 [{atomic,ok},{atomic,ok}]
3 2> db_init:add_groups().
4 ok
Then start the frontend node:
$ ./bin/start_interactive inets frontend -name fe1@erlang.local
After a short while we should get a logger message informing that backend server has connected to us:
=INFO REPORT==== 4-May-2009::16:28:21 === e_fe_proxy module, 'fe1@erlang.local' node, backend server registered 'backend@erlang.local'
That's it - we have distributed the service to two nodes: test if it really works correctly.
Steps further
The distribution using more than one frontend servers is easy as a pie: we must only change the fe_servers configuration parameter on the backend side and run another node with the given name - everything will work as it should (if you will try to do so on the localhost it will fail - simply because of the web server's port conflict. To avoid the error ensure the frontends have different port numbers - e.g. 8080, 8082, 8084 and so on. The port numbers can be changed in the inets.conf file).
Download
This tutorial step is over, the package containing the sources of the application can be downloaded from here.