Broadband-Hamnet™ Forum :: Applications
Welcome Guest   [Register]  [Login]
 Subject :EBOX Nodes, with Distributed Services.. 2014-12-19- 09:55:53 
VA7WPN
Member
Joined: 2013-04-29- 12:21:43
Posts: 60
Location: BC, Canada
 

So, Im a soldier, and I live in an earthquake/tsunami zone. We have these things called EBOX's, they are a sea containor with some survival equipment and supplies. They are situated around the base to support various numbers of people in various units incase of an emergeny like the ones listed above.

Simply put, their communications system is VERY ineffective. Basicaly there is a CB with a mag mount to toss up on the top of the container. then there is the process of reporting in.... That quickly turns the whole comms setup into a giant crap shoot. Everyone is panicing, wants their turn NOW, and none of them follow any kind of rhyme or reason as to what and how they report that into... Who's listening?? lol So, I am devising a Mesh system to utilize in my community which also has these same EBOXs, but also has ham radio operators associated wtih them.

What I am working on at this point is to have a Raspberry PI act as a host for a local webpage that looks like the images attached to this post. Each EBOX will record its boot time, this boot time will help determine the operation of the services mesh provides. As in, even if EBOX1 boots at 9:00, that doesnt mean its the control host of the (HTTPS & IRC). EBOX8 May have been booted first, at 8:55. Making it the control host. The services being hosted across the mesh are, an IRC, PBX, GeoServer, HTTPS, and hopefuly a method of file sharing.

The reasoning behind determining the boot up sequence, is so that not one node is responcible for all of the load of the services. Services will be booted in a predetermined sequence according to priority. Each node will have to run the HTTP service for their local operation, I will need to decide what to use for reporting.. SSH??.. After that, the next node will run the IRC, then GeoServer, then PBX last. This would requier at least 4 nodes to be fully functional. If I impliment a system to check time and load, the distribution of non-operating services can be started by the nodes with the least amount of load after say a 30 min count down.

This "Load balancing" and "Boot Sequencing" doesnt make any one node the Control Node. A, for lack of better terms, rank structure will dictate what individual is the Controller, and thus wich node is the control node. Just as most nets are operated.

The layout, and basic function of the site I am okay with. How ever, the integration of the rest is going to be the part I need the most work on. Such as, the reporting of individual nodes, and those stats showing up on the other remote nodes in the master tab. i know there is a lot of work to be done, and I will do what I can. I may be asking for assitance or ideas as I go.

For anyone who may not know... the GeoServer application I wish to use, is a kind of standalone, opensource "Google Maps". It has GPS integration, and does not requier an internet connection to operate once it has been setup. The maps are localy stored, and accessable without the need of any outside sources. Which makes it great for this kind of setup.

Any suggestions, or insight are greatly appreciated!

Thank you for reading!



IP Logged
 Subject :Re:EBOX Nodes, with Distributed Services.. 2014-12-19- 12:08:43 
KG6JEI
Member
Joined: 2013-12-02- 19:52:05
Posts: 516
Location

You may want to be careful with the choice of HTTPS/SSH as both are encryption that obscure the message, it tends to be a hot button topic with many ops and may create some interesting discussions, some times its just easier to avoid having to discuss.


The bigger items I want to bring up are to help you think the scenarios here for the bootup (these are ask your self questions not  questions I'm asking for answers on)

What happens when 2 networks are isolated and than become joined?  Do you run two masters at that point?

Why are you separating the services away from a single node? Is this really an advantage?(note: i want to quantify that 'distributed' design of loosing maybe the file server but not the chat server at the same time DOES count as an advantage) 

What do you consider a 'load'?  We can talk CPU load, we can talk network load etc.

Have you thought about the services trying to move to a more central in the network node based on routing data (a node in the center of the network will give you much better network reliability than a node at the far end of the network)

Everything was working great and someone bumped the power at one of the boxes, the box that has been controlling one of the services (and has all the data)  reboots quickly, but now has an uptime of minutes, what about its data set? Is it being published around or can the network rebuild that data?

Essentially you are talking about Cluster management for an Active/Passive infrastructure with a highly dynamic topology... Very powerful when done right, very code intense to build right. Just wanted to get your brain stirring, the idea sounds good in concept, just wanted to give you ideas on things in the backend to think on.

The basic services you want to offer sound exactly right and provide a method to hopefully make life easier for you, just an implementation item.

IP Logged
Note: Most posts submitted from iPhone
 Subject :Re:EBOX Nodes, with Distributed Services.. 2014-12-19- 12:53:17 
VA7WPN
Member
Joined: 2013-04-29- 12:21:43
Posts: 60
Location: BC, Canada
 
These are all great questions, and Im writing them down. :) The reasoning for the distribution of the services has to do with CPU load, My intent is to run these services threw a node that has a Raspberry PI as its backend. For instance, running just the GeoServer, or MapServer would be a heavy load for a raspberry pi. Adding on other services would put stress on the Pi. The distribution also gives some survivability to the network services. As I see it, a 24 hr rsync between all of the nodes data files would allow for this kind of "Hot Swapping". Clustering with the raspberry pi is a very common project, so I think that this could be a solution for this project. Again, if a node hosting a service goes down, an other node can pick up the service with minimal data lost, and down time. Network load is of concern as well, as 12 nodes all accessing all of these services at one time will make for some serious traffic. Regardless, of the physical location or approximation, the network will cover an area of about 2km x 2km. I will have to build antennas, to account for that. Also, if I ran all those services on a central node, and that node does not come up, we would be way worse off then a distributed system. Now, we can look at "Location Loading", meaning, once the connections are established, and services are up, having the services handed off to nodes that are, more suitably located to relive network loading. Both of these are something I would have to work out, and figure out. Its not going to be an overnight solution. Id like to say.. maybe by next December.... lol... Maybe if I had a team of code guru monkeys! Thank you, KG6JEI
IP Logged
 Subject :Re:EBOX Nodes, with Distributed Services.. 2014-12-19- 19:53:30 
KG6JEI
Member
Joined: 2013-12-02- 19:52:05
Posts: 516
Location

Sound like you are thinking it through and should go well, hope I gave you enough to ponder to understand the final plan and knowing where the limits are. Of course I realize as I put all those questions in I might cause you to make the mistake I often make, waiting for everything, often the solution that exists is better than the solution that is still being built.  Take it in stages with the grand scheme in mind and hopefully you won't have to wait till next December to have something to work with.

Good luck! 

IP Logged
Note: Most posts submitted from iPhone
 Subject :Re:EBOX Nodes, with Distributed Services.. 2014-12-20- 12:25:53 
VA7WPN
Member
Joined: 2013-04-29- 12:21:43
Posts: 60
Location: BC, Canada
 
Yes, you did. You got some things set in my mind now. And Im working threw some parts of them as we speak!
IP Logged
Page # 


Powered by ccBoard


SPONSORED AD: