NAStySAN

Links

If you are looking for something like NAStySAN today, perhaps have a look here:

NBD, the Network Block Device (TCP version), is already is in the Linux Kernel distribution since 1.1.x in /usr/src/linux/drivers/block/nbd.c
It is quite simple but functional, however it is not safe against networking errors of any kind.
To use it you need some user level programs. For your convenience I have a local copy for the tools I found were working (it seems to be version 14).
NBD has a Sourceforge Page, too.

The Enhanced Network Block Device Linux Kernel Module (I never tested it)
This is an improvement over nbd. It is better suited against networking errors and allows SSL to be used.
The interesting part for me is that it is multithreaded.

There is Drbd is a block device which is designed to build high availability clusters which allows you to mirror a block device over the network.

These projects seem sufficient to me, so why another project?

NBD is very small and easy if you look at the Linux kernel driver, I regard this as very beautiful. However look at the differences of ext2 and ReiserFS, only look at the journalling code and you will see: Sometimes small and beautiful is not enough, you need more features. The enhanced version added such features, however I think this is not the way I want to go.

I want to be able to use an NBD type blockdevice like any blockdevice at boot time without any helper applications in initrd etc. NAStySAN shall acomplish this the easy way if you think of an Ethernet card like a SCSI adapter. And nobody talks about using SSL to your hard drive (at least today). Additionally it might be feasible to port NAStySAN to another platform than Linux as well.

You need networking to be set up before you can use IP like in NBD. This is troublesome if you want to boot directly into single user mode.

I want some real type of autoconfiguration which is easy to remember. Something like mount /dev/nastysan2 /mnt should be enough for NAStySAN to grab /dev/eth2 and mount the default volume from the hardwired server. Don't confuse this with NFS, as NFS is a filesystem and not a block device. This way it shall be sufficient to give root=/dev/nastysan2 on your LILO commandline to boot from your NAStySAN.

I dislike any complicated options to remember, so everything more "advanced" than last example must rely completely on DevFS. If you want to mount a particuliar device on a particuliar server this must be as easy as mount /dev/nastysan/eth2/volume2 /mnt2 to mount volume2 over eth2. Perhaps this even can be integrated into the kernel at boot time but I already think this is too much ;)

To mount a device redundantly over two ethernet cards with load sharing 'n stuff, this shall look like mount /dev/nastysan/eth2+eth3/volume2 /mnt2. Yes, I really like such easy thingies, such that you even can use md style software RAID over NAStySAN as you like.

There must be options to NAStySAN, like timeouts and the like, however I want the client side (where the NAStySAN kernel driver is used) to get the defaults from the server such that you can alter the parameters from the server side. The idea behind this is that you can do a reboot one of the NAStySAN servers while the clients are not stopped and accesses do not break. Therefor can change the options of timeout and retry accordingly and then shutdown the server, fix it and restart it again, without interfering with the client. This way the client can be free of any configuration besides the knowledge which ethernet card to use for NAStySAN.

FAQ:

Who owns NAStySAN?

Valentin Hilbig
Karlstr. 30
84034 Landshut

When was it registered?

The Domains nastysan.com nastysan.net nastysan.org nastysan.de were registered 2001-06-01 after a check that neither "NastySAN" nor "Nasty SAN" were used anywhere in Internet prior art.
The name is not public domain but hereby I grant the irrevocable rigth that it may be used freely for any free software product according to the GPL.
Except for nastysan.com I am be willing to hand over these domains to other people, where nastysan.net should be reserved for all languages in TLDs where some cybersquatters tried to make some money. Don't even think about it, nobody will ever pay any cent for your domain, just hand it over to the Open Source community and we are friends again.
nastysan.com shall be the top level "binding" portal which I want to hand over to any company best suited to contribute to NAStySAN and Free Software. However this can be revoked at any time.
In the meanwhile everything will be handled by my own server platform.

May I use the name NAStySAN or "NAStySAN compatible" or something like it in my propriatary commercial product?

This depends, best you contact me. Note that I cannot prohibit if you use it without permission, but this would be really bad manners.

• If your product is Open Source (not neccessary GPL) then the answer is probably yes.
  But be aware that I really really really dislike any companies utilizing only the nice wording Open Source without contributing to the Open Source community for real.
  Read what rms says about this.
• If you really contribute to Open Source Community for example by funding NAStySAN developement the answer is pobably yes, as long as you continue to contribute.
• If you only want to attach your prorietary product to a NAStySAN server but don't want to help the community, then probably no.
• If you are Microsoft, as long as you don't apologize for Ballmer's "Cancer" quote publicly, then definitively no.

What is NAStySAN?

It does not exist yet.

Why NAStySAN?

Because we need a cool name for such a thing.
If you want to know why I want to invent NAStySAN then I can only tell you that it is the first step for another long term project (don't try to follow that link, it is not yet there) which is called de-serf and perhaps sometimes will come into the real planning phase.

So when it does not exist and has only has a cool name, what NAStySAN stands for?

NAS is Network Attached Storage and SAN is Storage Area Network, ty stands for "type" and is only a linker betrween because I thought it is a cool name.

OK, I know what NAS and SAN are, do you plan some Network Attached SAN or what?

No, I thought the opposit, a NAS type SAN would be nice. Therefor the name. This would be a SAN on a Network layer, but it is not directly network attached.

Now, what kind of problem do you have?

I have several problems:

• RAID5 only allows ONE hard drive to fail. A combination of RAID1 and RAID5 allowes TWO Harddrives to fail, but DOUBLES the number of Harddrives you need.
• If you buy one Harddrive, you cannot easily add it to a RAID to extend the Volume. This is because the Parity of RAID5 is distributed about all Volumes.
• It yould be feasible to add a Harddrive to a RAID4, but then you have a hot spot on the Parity Drive.
• All RAID Harddrives need to be the same size but it's best to always buy Harddrives with the best money/storage ratio.
• SAN is expensive but would be the right idea.
• NAS is nice, but it's more easy to to think in terms of huge Fileservers. But if you change the configuration of a Fileserver this usually brings a downtime.
• Usually I don't have room to put the Harddrives in the casing. I even don't have any room in the same Rack to add external storage containers.
• Backup. The size of harddrives of the same price doubles each year. The backup systems only have a linear degression. In 2 years or so harddrives will be cheaper than backup medias!
  Even that DLTs are relatively cheap today compared to the backup size, for the price of one DLT drive I can buy me arround TWICE the storage I have today which is arround 200 GB.
  So something is definitively wrong if you expect that BACKUPs will be MORE EXPENSIVE than NEW STORAGE.

No, I wanted to know what kind of personal problem you have!

Sigh, no comment, it would be far too long. Perhaps have a look into my homepage and find out yourself.

What do you want?

I need a NAS type SAN, I need NAStySAN. Following should all be easy

• to access the SAN over Ethernet from anywhere
• to add new harddrives
• to take harddrives offline permanently
• to replace harddrives
• to put harddrives anywhere in the network you want
• to make internal snapshots instead of backups
• to archive old snapshots away
• to have an online backup like a transaction log
• to mount a volume directly from GNU/Linux
• to run a computer while something is unavailable in the network

What do you want NOT?

Of course you have some drawbacks with such a thing, so I don't want

• highest speed
• boot directly from NAStySAN
• particuliar hardware needs
• to depend on proprietary hardware or software
• access this from Windows directly
• closed source
• to re-invent the wheel
• to be let alone

Doesn't look like a piece of cake. How do you think it can be done?

Here is the layout:

1. Incorporate a block driver into Linux which accesses NAStySAN over an Ethernet card.
2. Write the NAStySAN Daemon to attach to an Ethernet card to map the NAStySAN block device to any registered Harddrives.
3. Extend the NAStySAN Daemon such, that remote Harddrives from other NAStySAN Daemons can be registered, too.
4. Extend the NAStySAN Daemon such, that it can run in a failover environment, such that one Daemon takes over if one fails.
5. Base this all on GPL. I thought over making it with the lesser licence, but as Ballmer calls Linux a Cancer I don't want that Win2000 is infected ever.

Here are some basic things I want:

1. NAStySAN will only run on a dedicated Ethernet directly on the MAC layer. It doesn't need the IP layer, but you will need a dedicated NAStySAN ethernet card.
2. NAStySAN thinks of security in terms of physical separation of the NAStySAN connection from all other network traffic. So there will be no security in the protocol.
3. NAStySAN thinks in terms of a direct physical connection of the block driver to the Deamon. However both sides should be able to deal with more than one virtual connection over one ethernet card.
4. AFAICS you will be able to use the NetLink driver to communicate from Linux directly to NAStySAN. However this is not recommended as this might trigger some Henn-Egg-Problems, for example if you place the Swapfile on a NAStySAN volume. Perhaps some kernel threads can be written for some encapsulation.

Some more notes on the first NAStySAN version:

1. It will only run on 2.2.x kernels with x>=18 (or perhaps 2.4.x with x>=2)
2. It will only allow a 1:1 connection.
3. It will not have any idea of redundancy. This you have to do with MD, either on the Linux side or you directly register a MD as a NAStySAN volume.
4. It will not contain any Logical Volumen Management of any kind. So you have to use the LVM of Linux or to register a LVM as a NAStySAN volume.
5. It will not have any transaction log or snapshot options
6. It is very likely that it is not compatible to the second version. However there will be an option to register Harddrives the old way.
7. It will be dead slow as there is no kernel thread
8. However it will be safe against networking or transaction errors. So you can change the wiring while it is in action without any fear or shutdown the server while in the middle of operation.

When?

Who knows?
Currently I wait to build my test platform.

Where?

Sourceforge.

Can I help?

Of course! See Souceforge. But be aware that the project is in the "pre-planning-phase" and might stay there till 2010. OOPS.
If you want to support me, I have a wishlist