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.imgStarting 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.imgIf 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
Working With XenSetting 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-clientTo 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/remoteNow we can play:
for i in $(seq 1 100) ; do echo $i > /mnt/remote/$i; doneUnmount the volume:
root@yours:/# umount /mnt/remoteNow 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+foundFun, huh?
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..
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 ]
[ 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.
[ Parent | Reply to this comment ]
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 ]
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 ]
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 ]
[ 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.
[ Parent | Reply to this comment ]
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 ]
[ 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...
[ Parent | Reply to this comment ]
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 ]
Could iSCSI be the solution to this problem?
[ Parent | Reply to this comment ]
rgds Markus
[ Parent | Reply to this comment ]
Anyway, I like this thing that demonstrate the power Unix/Linux world, where all things are files :)
[ Parent | Reply to this comment ]
[ 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.
[ Parent | Reply to this comment ]