The Load Balancer is ready for prime time

The Apocalyx frontend is not yet ready, I am still messing around with that and well it's not showing yet anything, but soon, very soon. BUT, the Load Balancer (LB) is ready to be integrated into SMASH. The LB will check for speed on each connected node and how many processes are running, then it calculates what that means in terms of availability for the cloud. This game is a zero sum game, but for the final evaluation, every single node will count, negative values are not permitted, then the total percentage is done. For the end user there are 2 procedures to be called, remote rpc (rrpc) and remote spawn (rspawn). rrpc will spawn a procedure remotely and wait max. for one sec for the result or rspawn will spawn a procedure remotely and return the PID, in case that the procedure takes longer or you need to spawn a server. Those 2 procedures should do for the generic cloud service. This might even mean a strong impact on the Simulation itself that will run on the framework, the initial idea was to run a zone one a single node, but with the LB there is really no need for any kind of restriction, you could run the Sim threads all over the place. Let's see what that does for the framework :) .

Cheers,

Sunweaver

Some more remote utilities

Some might know that SMASH has included into its belly an automatic updating system, which allows to compile all modules and reload them on all connected nodes in run time, without ever shutting the system down. On occasions this fails and a certain service shuts down. To get a hang on this, we have created some utility routines, one permits to execute commands remotely (on the other nodes) and the other shows if any module is executing old code, so very soon we will be able to first check what module on which node is executing old code before a new compile is allowed. So far the problem seems only to reside on longer lasting timers, which are not included in the update signal, all others update correctly (it seems). Also with these utility routines we could now easily start all preconfigured services (in the cluster file) remotely, without needing to touch then anymore. Some other fixes are that the CC proxy can now send tells or whispers without subscribing to any channel; KVS can now cache and forget, when you ask kvs:cache(M,F,A,Timer) it now will update every "Timer" ms and forget about the value after a minute, so the dictionary does not pile up with hundreds of unused values, this works like a garbage collection to keep KVS trim and slim. And more tests on Mnesia have been executed and curious enough on remote nodes the dirty function is slower than the normal database access with transactions and as to be expected KVS suffers from the initial Mnesia access, but afterwards blazes thru repeated accesses, so no matter how much we try to optimize the database access, the cached behind KVS approach is still the best when repeated access to data is required. Dedicated MMO literature also comes to the conclusion that processes on a multi server structure should update their data every 5 sec., less seems to be too much. And the cloud infrastucture has given some new ideas, Erlang already has the ability to spawn remote processes, so I guess, we just might implement our own flavour of it, by speed measuring each connected node and on the other hand check how many processes are already running there, this could be something like a routine task that executes per "X" interval and then when asked to spawn a process it checks for the best node to do so, a kind of "cloud_spawn(M,F,A)". This would make the SMASH ready to process any kind of task actually, not just a specialized Simulation Framework. It just might happen =) .

And Apocalyx can indeed use tables to store toon data, I played around with the Urban Tactics demo and it can easily handle some 200 toons running around there, very nice, now we need this networked. ;)

Laters,

Sunweaver

Does SMASH do Cloud Computing ??

I was asked the other day if the SMASH does Cloud Computing or Grid Computing [cf. Cloud Computing from Wikipedia] and the answer is that while there is still a lot of ground to cover, in essence that is what the basic framework will do. The Load Balancer (LB) will check for the best resources to allocate (this is still future music) and distribute the simulation accordingly. The basic idea is the same, if you look at the graphic on Wikipedia, the cluster table (that we will have at some point and which will define how the cluster should behave) corresponds loosely to service catalog, the provisioning tool basically does what the LB will do and the Monitor is in essence what the Observer does. Once the pieces fall in place we will obviously also need a Systems Management component, which might be part of the cluster behavior.

So, given that this project was started like 4 years ago, the word "Cloud Computing" did not exist at that time, it seems to have formed during late 2007, but the idea of covering massive computations by networking them on many servers, instead of a large scale server is the same, so in essence I guess, SMASH is a Cloud Computing Framework and what's more, thanks to the unbelievable Virtual machine that Erlang runs on, we can already run cross-platform, the test cluster SMASH is being programmed on, consists of Windows, Linux and MacOS X systems.

Cheers,

Sunweaver