Working with network block devices

Posted by Steve on Thu 2 Aug 2007 at 09:43

There are times when you have a machine, or two, which is short of disk space and yet you have spare capacity elsewhere upon your LAN. For these times using a Network Block Device could come in handy. This allows you literally export files as block devices remotely.

As another useful tip because the disk activity is going over the network you can filter or rate-limit IO in a simple fashion.

For example imagine you were running a lot of Xen guests upon a single host and you didn't want a greedy client performing a lot of I/O operations to adversely affect the other users of the machine. This is hard to manage by traditional methods, but using iptables you could easily manage it.

There are drawbacks to using network block devices, and I'm sure they are obvious:

  • You're limited by the speed of your network - which is probably lower than the speed of your disks.
  • You must care about security a lot.

In the system we're going to describe we'll have two machines mine.my.flat and yours.my.flat. The first will export a single file, which will be mounted upon the second. We'll use port 1234 for this, and we must firewall this port such that only the client system which is supposed to connect to it can.

Server Setup

Setting up the server is pretty simple. We'll need to install the software, prepare a device, and then export it.

To install the server run:

root@mine:/# apt-get install nbd-server

Now we'll create a file to export:

root@mine:/# modprobe nbd
root@mine:/# mkdir -p /home/exported
root@mine:/# dd if=/dev/zero of=/home/exported/trial.img count=256 bs=1024k
root@mine:/# mkfs.ext3 /home/exported/trial.img

Starting the server should be simple, but I found that it immediately segfaulted on my machine - so we'll demonstrate two commands for this:

root@mine:/# nbd-server 1234 /home/exported/trial.img

If this errors like mine did run this instead:

root@mine:/# touch /root/empty
root@mine:/# nbd-server 1234 /home/exported/trial.img -C /root/empty

(There is a global configuration which can be used to list exports /etc/nbd-server/config - however everytime I tried to use this file I received a segfault from the server process so I can't tell you anything useful about it.)

Setup The Client

Setting up the client is very similar to setting up the server, we need to install the relevant software then mount the remote image.

root@yours:/# apt-get install nbd-client

To mount the system we'll run:

root@yours:~# nbd-client mine.my.flat 1234 /dev/nbd0
Negotiation: ..size = 262144KB
bs=1024, sz=262144

root@yours:~# mkdir /mnt/remote
root@yours:~#  mount /dev/nbd0 /mnt/remote

Now we can play:

for i in $(seq 1 100) ; do echo $i > /mnt/remote/$i; done

Unmount the volume:

root@yours:/# umount /mnt/remote 

Now try mounting it back upon the server, to make sure that those files have persisted and been created as we expect:

root@vain:~#  nbd-client 127.0.0.1 1234 /dev/nbd0
root@vain:~# mkdir /tmp/foo
root@vain:~#  mount /dev/nbd0 /tmp/foo
root@vain:~#  ls /tmp/foo/
1    14  2   25  30  36  41  47  52  58  63  69  74  8   85  90  96
10   15  20  26  31  37  42  48  53  59  64  7   75  80  86  91  97
100  16  21  27  32  38  43  49  54  6   65  70  76  81  87  92  98
11   17  22  28  33  39  44  5   55  60  66  71  77  82  88  93  99
12   18  23  29  34  4   45  50  56  61  67  72  78  83  89  94  
13   19  24  3   35  40  46  51  57  62  68  73  79  84  9   95  lost+found

Fun, huh?

Working With Xen

I spent a while trying to get this working with Xen, but only found success when using the /dev/nbdN devices.

For this to work I had to use the following Xen configuration, which is less than ideal:

disk        = [ 'phy:vain-vol/etch-builder.my.flat-disk,sda1,w', 
                'phy:vain-vol/etch-builder.my.flat-swap,sda2,w',
                'phy:/dev/nbd0,sda3,w' ]

I had hoped to be able to specify the host + port inside the disk stanza, so that I could be sure of device ordering - but I couldn't make that work.

Any suggestions welcome..

Share/Save/Bookmark


Posted by wuzzeb (64.5.xx.xx) on Thu 2 Aug 2007 at 10:23
[ Send Message ]
for i in $(seq 1 100) ; do echo $i > /mnt/nbd/$i; done

Should probably be echo $i > /mnt/remote/$i


Secondly, (I haven't tried nbd yet), but for the xen configuration it seems like you pass the device file name to use to nbd-client... why not just put the server and port into the device filename... something like

# ndb-client server 1234 /dev/ndb.server.1234

And then in the xen configuration use /dev/ndb.server.1234,sda3,w

[ Parent | Reply to this comment ]

Posted by Steve (80.68.xx.xx) on Thu 2 Aug 2007 at 10:27
[ Send Message | View Steve's Scratchpad | View Weblogs ]

Thanks - I've fixed that error now. (That'll teach me to switch from the real paths I was using to 'friendlier' ones!)

I'll try your Xen suggestion this evening and see how it works out. It's not quite as nice as having:

nbd:/nbd-server.name 1234,sda3,w

But preferable to what I ended up with.

Steve

[ Parent | Reply to this comment ]

Posted by mvanbaak (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Thu 2 Aug 2007 at 18:48
[ Send Message ]
Beware you can only mount the exported blockdevice on 1 xen instance or other server when using ext3 as the filesystem.
If you want to mount it on more vm's or boxen you have to use ocfs2 or gfs (or any other cluster aware filesystem)
As this sounds easy, I found out this can be a real troublesome setup.
We even gave up and went with NFS in the end.

[ Parent | Reply to this comment ]

Posted by Anonymous (68.229.xx.xx) on Fri 14 Sep 2007 at 23:48
I've used iSCSI (openiscsi initiator + iSCSI Enterprise Target) to export logical volumes out as block devices.


Then on remote hosts using Xen or KVM/Kqemu/qemu I could use those as disks and have the install cdroms partition them and format them as if they were real disks.

Using iSCSI alone doesn't provide you a way to share a single file system out among multiple VMs or machines like running OSCFv2 on iSCSI or GFS on GNBD or iSCSI, but it's nice for sharing disk space.

Also iSCSI is very robust and this method allows you to support non-Unix-like systems (aka Windows). If you do a good job designing your network with good nic cards that support jumbo packets and good switches that also support large MTU sizes.. and maybe through a couple bonded gigabit nic interfaces you can get VERY close to native disk speeds. Faster then NFS, generally.

But unlike NFS your severely limiting the number of clients you can support.

[ Parent | Reply to this comment ]

Posted by mvanbaak (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Thu 2 Aug 2007 at 18:48
[ Send Message ]
Beware you can only mount the exported blockdevice on 1 xen instance or other server when using ext3 as the filesystem.
If you want to mount it on more vm's or boxen you have to use ocfs2 or gfs (or any other cluster aware filesystem)
As this sounds easy, I found out this can be a real troublesome setup.
We even gave up and went with NFS in the end.

[ Parent | Reply to this comment ]

Posted by Steve (62.30.xx.xx) on Thu 2 Aug 2007 at 18:50
[ Send Message | View Steve's Scratchpad | View Weblogs ]

Mounting it only once isn't an issue if you're running it as a backend storage for a Xen guest, etc.

But I didn't mention that explicitly so thanks for bringing it up.

Steve

[ Parent | Reply to this comment ]

Posted by mvanbaak (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Thu 2 Aug 2007 at 20:24
[ Send Message ]
that is if you dont want to do live migration. then you need to mount it on several machines as well.

I'm still looking for a good stable setup for things like this.
We tried gndb with ocfs2 and gnbd with gfs but they both are pretty unstable.
I bet a real netapp or fiberchannel storage will perform way better but if you can afford that, you can also afford vmware infrastructure and that's always nicer when dealing with legacy operating systems.

so if someone has a good hint with real usecases I would be very interested.

[ Parent | Reply to this comment ]

Posted by Steve (62.30.xx.xx) on Thu 2 Aug 2007 at 21:38
[ Send Message | View Steve's Scratchpad | View Weblogs ]

I don't use Xen in a live-migration capable environment, but I did test NFS with a high degree of success...

Steve

[ Parent | Reply to this comment ]

Posted by mvanbaak (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Thu 2 Aug 2007 at 22:20
[ Send Message ]
Cool. I'm waiting for my new thinkpad to arrive. This one will run xen as well and I can test NFS setups for live migration.
At work we switched to NFS mounted storage located on a netapp with vmware. This gives us the support options we need for our customers.
Here at home I run xen on several machines using their own RAID1+LVM setup for storage.
With the new laptop I can run 2 laptops with xen and the main storage machine with NFS to see how this works.
I'll keep you all updated
(Laptop will arrive 08-21 so please be patient, I have to be patient as well)

[ Parent | Reply to this comment ]

Posted by eric (194.2.xx.xx) on Fri 3 Aug 2007 at 08:57
[ Send Message | View Weblogs ]

Could iSCSI be the solution to this problem?

:eric:
http://blog.sietch-tabr.com

[ Parent | Reply to this comment ]

Posted by Anonymous (130.233.xx.xx) on Mon 13 Aug 2007 at 06:51
Also in iSCSI you need to use cluster-aware file system to be able to mount the same file system on several computers (virtual or real) and write to it. Even having one system to mount file system read/write and other using read-only does not work, at least for ext3. Check ext3 mailing list archives for discussion.

rgds Markus

[ Parent | Reply to this comment ]

Posted by Anonymous (217.7.xx.xx) on Wed 8 Aug 2007 at 13:50
I'm wondering what are advantages of this method over NFS. I understand that this is more efficient, but it's complicated and not easy to maintain. Moreover, basic security is already provided by NFS.
Anyway, I like this thing that demonstrate the power Unix/Linux world, where all things are files :)

[ Parent | Reply to this comment ]

Posted by Steve (80.68.xx.xx) on Wed 8 Aug 2007 at 16:12
[ Send Message | View Steve's Scratchpad | View Weblogs ]

The simple answer is that both could be used - I like this solution because it is explicit about one IP per device, which would allow the firewalling to be simpler.

Steve

[ Parent | Reply to this comment ]

User Login

Username:

Password:

[ Advanced Login ]

Register Account

Quick Site Search