High Availability Plan

Here's the latest plan: ha.pdf.

I have been kicking around some ideas and testing a few things to find the best solution for high availability. Using a MySQL cluster has it's limitations that need to be dealt with.... the biggest one would be that clusters use the NDB (network database) storage engine which is an in-memory storage engine. All data and indexes are held in RAM - Not only that but you are holding a copy of the data and indexes for each node in RAM (if the db is 500MB, you would need 1GB of RAM with two nodes because you have two copies of the data.).

To overcome this limitation i will be using a combination of replication and clustering. Much of the data in the database is configuration and customization settings. This is all configured from within Zone Control on the Master server. This data will be saved to a master db on the master server. Two slave db's will update the authservers with the changes made in this master db. All updates to configuration data will be made to the master db for replication to the authservers. Any reports or other viewing of data will be queried from a slave. The slaves will hold the complete db because the user table and accounting will not be replicated, but clustered. Any records that are created or updated by the gateway will used the storage cluster to maintain high availability.

This all sounds very complicated but it's really not that bad. NDB is a very cool db engine. To use it all i have to do is create a table on one slave with engine=ndbcluster and the table will be available to both storage nodes the instant it is created. Any inserts or updates are available simultaneously to both node. I guess my biggest concern is not the setup, but disaster recovery. I'll be practicing f'ing things up for a while :-)

More on System Design

All this posting reminds me of the old days... well OK, it was a year ago - not that old. I have another diagram. This one is the best one yet. It does a good job of showing the overall architecture of the entire system: nodes.pdf

As mentioned, the gateway will provide high availability and load balancing for the two web servers. WiFiDog's ping program will check server availability. Note to WiFiDoggers: I tweaked the server to only reply with "Pong" if the db update is successful. That way the server will failover for a db connection failure and not just a web server failure. And for load balancing, the web servers will use three domain names. The three domain names will be phobos.publicip.net, deimos.publicip.net, and rover.publicip.net. The "phobos", and "deimos" subdomains will be the two names assigned directly to the web servers used for authentication. The "rover" subdomain will be setup using DNS round robin that points to both authentication servers. Configuration downloads with use the rover subdomain. Whatever server the config is grabbed from will be the primary server for the gateway. That's why i am not using names like auth1 and auth2, it implies a primary a secondary, besides fear and panic is more fun :-)

Some More Info...

Here is another diagram that takes you a little bit more into the new system setup: cluster.pdf. I'll be putting together a few more of these over the next couple of days to help show how things will work.

I will also put more together on how the zonecd will work with the new, old, and private servers. The way i see it now, there will be three "Closed" modes of operation and one "Open" mode to choose from... WiFiDog will not replace NoCat on the zoneCD. They will coexist. During boot you will be prompted to select from four modes:

1. Premium Service
2. Private Service
3. Free Service
4. Open Service

Premium, and Private service will use WiFiDog and the new control server. Premium will be the service provided by PUBLICip, Private will be your own server setup using the WiFiDog source i provide.

Free, and Open service will use NoCat and the current control server, and NoCat in Open mode.

World Domination

OK, so it's not exactly a reasonable goal, but i have made it this far... i have no plans on stopping. I guess i am aiming a little high - but that's what makes me who i am ;-) Over the next couple weeks i will be posting more detailed plans on where PUBLICip is headed. I will start with an overview and a brief description of where we will start and how...

Before i start into the future, let me remind all of you that the goal of PUBLICip has never been to release source code. This project's goal is to provide a simple solution for providing safe and secure [wifi] public internet access. Most open source project's are created with similar intentions and goals... Île Sans Fil gave us WiFiDog, as Seattle Wireless crafted NoCat. PUBLICip's goals may be broader, but our main goal is the operation and administration of public wifi authentication and control servers. Source code availability is a secondary goal but still very important aspect of what is happening here.

OK, buckle-up here we go... download this pdf as a reference. I would consider this diagram to be about 5 years into the future. The diagram in the pdf is a little misleading because it got ugly real fast trying to diagram all the servers (I will be revising this diagram and creating more detailed lower level diagrams and descriptions as we move forward).

Starting in the North American continent, we will begin building clusters of authentication nodes controlled by master nodes. Referring to the diagram; each control system will actually be comprised of five servers. Each cluster will contain two data storage nodes, and two sql nodes. A web server will also be running on each of the sql nodes. The two web servers will host the authentication, control, and support programs. Two synchronized web servers will enable the gateways (zonecd's and wrt54g's) to provide load balancing and high availability. Load balancing will be achieved by alternating primary and secondary servers for each successive config download, while high availability is achieved using a web query (wifidog's ping) to determine the server's availability. Web server synchronicity will be achieved using rsync over ssh.

The master node will run management software for the database cluster, host the web ui for zone control, and host the http://www.publicip.net/ website with forum and support system, or the website of the individual or organization supporting the cluster. Before you comment, the master node is not a single point of failure. It can be taken down and not one user session would be interrupted.

I am still pretty early in the planning stages, and i have left out a bunch of cool new features that will also be available. But i think you can see why the new server will not be free(as in beer) to use. The source code that will be freely available(as in freedom and beer) is that of the authentication nodes. The master node code will not be free(as in freedom) and will be distributed to trusted individuals only. It will not be GPL'ed but will be free (as in beer).

That's enough for one blog post....

I've got a WiFiMutt

It's official... I have shredded wifidog to pieces and it's now a new server. You could call it a mutt. All that remains is a few classes and some logic. It's changed so much that it could probably use a new name... Maybe I'll name my dog Spot.

All the fundamental coding for the new server is complete. Login and accounting is working beautifully. Any limit or class changes will automatically take effect in under a minute - You will not be required to logout and back in to update your class or other settings.

Not sure if i will make this an official distro, but the source code will be available via cvs to maintain compliance with the GPL agreement which WiFiDog is distributed under. However usage of the new public ip server will not be free (before you post any flames, you better read the GPL). Once i get a few of the configuration interfaces done, i will make the source code available for the server and gateway. It should only take me a couple weeks to get this to a point where you can take your turn at hacking it to fit your needs.

Wat up dawg.....

I've been having a "big hack attack" on wifidog over the last few days, and have added the things required to make it more like what public ip already has. I added the four classes we use, bandwidth throttling per class, configure unauthenticated access per mac/ip, and the transparent proxy for dg(even a remote proxy server can be configured). All these options are configured in a single configuration file... even the unauthenticated access has a structure in the config, instead of having to run a command to enable it.

Sooooooo...... now it's time to rip into the authserver and make that what i want :x First i will make the lite version for distribution work with a new zonecd, then on to a new production server for public use.

Back to work...