MooseFS taking shape

I am continuing experimenting with MooseFS. However, the final configuration looks somewhat different from what I had originally envisioned. For one thing, the idea of placing the master and metadata servers in VirtualBox VM's didn't quite work out. I guess that created just too many levels of execution and as a result that lead to the overall load growing too much and the performance suffering as soon as any serious load was applied.

So I switched to simply running all the processes (master, meta, chunkserver) on the same hardware and got rid of all the VM's. That worked fine. I defined a separate network - currently fully confined to the same host - in order to host the MooseFS installation. And MooseFS clients have started to run just fine. I got a performance of up to 80 MB/s for reading data from the MooseFS over a 1 Gbit/s network.

However, one problem remained. Running UNFSD on the same machine I got very poor performance.  As few as 5 clients could drive it down to just 30 KB/s! And that on an 8-core 48 GB RAM machine - while a MooseFS client would read at 3 orders of magnitude as much!

Surprisingly, the fix was simple: if I ran UNFSD on a separate physical machine the performance went back into the tens of MB/s range. So that was what I settled for. That NFS server machine is currently just a CentOS Linus MooseFS client sitting on the "general" network - different from the one hosting MooseFS - and sporting a mere 2 cores and 2 GB of RAM. So I guess for now I have a working solution.

MooseFS

Just reporting that I started playing with it - and more than playing. So far so good. The architecture is really simplistic, the executables very lightweight. For more detail see here:

http://www.moosefs.org/

I am running it on several server-class boxes using VirtualBox VM's to emulate a network so as to be able to distribute it to multiple hardware boxes later on. Both the VirtualBox hosts and the VM's are running CentOS 6.

The only problems so far seem to have to do with integrating MooseFS with other technologies. I tried using the UNFS3 user-space NFS server to create an NFS gateway to the MooseFS installation. And so far it looks like the UNFS3 server does not scale well to multiple connections. In other words, you get an excellent performance with one NFS client, you get a decent quality with 2-3 connections but when it is above 5 it seems to go down the drain and accessing one's home directory over such an NFS connection becomes pretty much unfeasible. So at this point what's lacking is a good NFS gateway for situations where a MooseFS client is for some reason not available or not a workable solution. Or perhaps I will choose a different sharing method. Time will tell.

Some pracitcal uses of VPN

VPN is a term one hears often these days. However, while many people have some ideas about what it is used for - secure access, for instance - many probably lack vision of how they could benefit from its use. So for starters - what is VPN? You can use the Wiki link for a formal definition but in a less formal way one can define it as a network one can build to their own design provided one controls the server and the other machines one intends to network together have the capability to access that server via the internet.

So let us say you control a machine on the Internet with a public IP address. On it you can install a VPN server process. Then you can issue authorization to those you want to allow to join your VPN network.

Let us consider a practical example. I configure a server to serve a VPN with a private network defined as 192.168.20.0/255.255.255.0. Let us say the server gets the virtual IP address of 192.168.20.1, with the other addresses (192.168.20.2-254) available for grabs. So let us say my laptop gets an address of 192.168.20.2, my home machine gets an address of 192.168.20.5 and my office machine gets an address of 192.168.20.10.

Thus - using the same network protocols - I can collect the video feed off of my home computer to see what is going on at home, print to my office computer's printer - and do all of it from a WiFi point half the world away using my laptop.

Or - let us say - in addition to my office in Boston I decide to get one in Buenos Aires. No problem. I get another machine there - let's say, with a virtual IP address of 192.168.20.15 - and use it and the one at my office in Boston - 192.168.20.10 - to link the two networks. Now they are linked - via the internet but at the same time utilizing the VPN's security which is normally considered an unrbeakably secure way to communicate.

Those are just a couple of possible usage scenarios. I will try to cover this topic in more detail later on. For now just think of the VPN as a network you can define the way you like no matter where the computers who will join it happen to be geographically and topologically. So long as they have access to the internet and you allow them to join your VPN they can do so.

The different flavors of 568

Yes, I admit this one was stupid. But cut me a little slack - last time I had to make network cables was many moons ago. And yes, I even got to make coax cables for 10 Mbit Ethernet. But no matter.

OK, so we got this spool of cable from a generic vendor with the cable labeled "ANSI/TIA-568-C.2". For some reason - looking at some pictures online, most likely - I decided that was to be wired according to the T568A layout. And wire them I did - a few cables, actually. Which worked fine in multiple jack with an exception of a Cisco Catalyst 2000 100 Mbit switch where they did not work at all.

Then I wired one cable to the T568B layout and it seems to work everywhere including that Catalyst 2900 switch. Given the T568C is said to have superseded T658B which in turn superseded T568A which is by now obsolete all of this seems to make sense. Hence it appears that the solution has been found.

Let me also take the time here to thank all those mailing list respondents whose guidance helped me figure this mess out. It always helps to have other minds to collect thoughts off of!

Reference:

TIA/EIA-568

Ethernet over twisted pair

How to wire Ethernet Cables

NFS on Mac

It is really strange that NFS on Mac OS X is an absolute mess even though Mac OS X is UNIX-based and UNIX/Linux machines NFS mount to each other easily and conveniently.

I just moved my NFS server from SLES 10 to Cent OS 5.5 and guess what - Macs just want nothing to do with it. Oh, well, to be continued.

Solaris the tree killer

Now how's this for a fun experience - I have got this Solaris 8 machine which for some reason finds it necessary to send a title page with every print job. It does not run its own spooler and prints via a print server instead so I am clueless as to where to look for relevant setting to turn this on. So, in the spirit of waste and insanity so characteristic of our times, the machine seems poised to turn a whole forest to waste in no time as it sends quite a few print jobs.

The only configuration it seems to have is contained in the /etc/printers.conf file which looks roughly like the following:

#
# If you hand edit this file, comments and structure may change.
# The preferred method of modifying this file is through the use of
# lpset(1M)
#
caslon:\
:bsdaddr=kiev,caslon:

garamond:\
:bsdaddr=kiev,garamond,Solaris:

bodoni:\
:bsdaddr=kiev,bodoni:\
:job-sheets-default=none

_default:\
:use=gutenberg:

gutenberg:\
:bsdaddr=nrims-fs,gutenberg:

Now exactly where to tell it to knock off that title page nonsense is anybody's guess... But if you know feel free to tell me in the comments and I will be eternally grateful!

Web-pandering to Mr Gates or...

What's the story, really?

Here is the story. A colleague of mine is currently staying at a hotel in France which offers WiFi services courtesy Meteor Networks. Now the way it works as I understand it is that you purchase time from the Meteor, then you establish a WiFi connection with the local router which at first channels you to their authentication page. There you authenticate yourself and off you go browsing at your leasure - until your time runs out, that is.

At least this is how things ought to be, according to the Meteor. Yet the reality of the situation appears to be a bit different. My colleague had stayed at the same hotel before and had tried using the same service and had discovered a rather strange pattern: the connection would kick in just fine if he booted his laptop under Windows and it would be defective every time he tried to boot up under Linux which is the OS he prefers to use. The defects would be missing blocks of webpages, malformated webpages and error messages indicating incorrect firewall/proxy settings.

My first thought upon hearing that was that Meteor - and its authentication engine - must expect Microsoft IE as browser and so, to deceive them, I set the HTTP ident sequence in the SeaMonkey browser on the laptop to identify itself as IE (IE 7 under Windows XP if I remember correctly). So off he went, and this time around when he fired off his SeaMonkey he can authenticate himself and connect to the web and receive his email via IMAP but can not properly browse as he keeps getting those annoying firewall/proxy related error messages.

I have emailed Meteor but have received no meaningful replies thus far. An engineer of theirs to whom I spoke on the phone yesterday could offer no good advice either as according to him all that's involved is simple DHCP initialization and web authentication after which you are good to go. According to him, there are no proxy servers involved.

So in short - I am puzzled. Any help in the comments or by email would be greatly appreciated. Specifically I guess the questions would be, what would cause this behavior? Can it be OS-related? If so, how? How do we tell - granted I have to do it from here and I can't get inside the Meteor's network.

Be that as it may - this is one good IT riddle, in my humble opinion. Have at it. And thanks in advance for any and all help.