73 lines
4 KiB
Markdown
73 lines
4 KiB
Markdown
|
---
|
||
|
|
date: 2013-02-25
|
||
|
|
title: The Linux to Storage
|
||
|
|
category: Opinions
|
||
|
|
---
|
||
|
|
|
||
|
|
Martin "Storagebod" Glassborow recently wrote an interesting article
|
||
|
|
where he asked "Who'll do a Linux to Storage?". As someone who is
|
||
|
|
equal parts Storage and Linux, the same question runs around my head
|
||
|
|
quite often. Not just that, but how to do it. It is safe to say that all
|
||
|
|
the constituent parts are already in the Open Source Ecosystem. It just
|
||
|
|
needs someone to pull them all together wrap them up in an integrated
|
||
|
|
interface (be that a GUI, CLI, an API or all).
|
||
|
|
|
||
|
|
Linux, obviously, has excellent NFS support. Until recently it was a
|
||
|
|
little lacking in terms of block support. [iSCSI Enterprise
|
||
|
|
Target](https://sourceforge.net/projects/iscsitarget/) is ok, but is not
|
||
|
|
packaged for RHEL, which for most shops makes it a big no-no. Likewise
|
||
|
|
[TGT](https://stgt.sourceforge.net/) is not bad, I have certainly used
|
||
|
|
it to to good effect, but administering it is a bit like pulling teeth.
|
||
|
|
Additionally, neither are VMware certified and I am pretty sure that TGT
|
||
|
|
at least is missing a required feature for certification as well (may be
|
||
|
|
persistent reservations). There is a third SCSI target in Linux though:
|
||
|
|
[LIO Kernel Target](https://www.linux-iscsi.org/) by Rising Tide
|
||
|
|
Systems. This is a lot newer, but is already VMware Ready certified. Red
|
||
|
|
Hat used it in RHEL6 for FCoE target support, but not for iSCSI. in
|
||
|
|
RHEL7 they will be [using it for all block
|
||
|
|
storage](https://groveronline.com/2012/11/tgtd-lio-in-rhel-7/). It has a
|
||
|
|
much nicer interface than the other targets on Linux, using a very
|
||
|
|
intuitive CLI, nice JSON config files and a rather handy API. Rising
|
||
|
|
Tide are a bit of an unknown however, or at least I thought so. It turns
|
||
|
|
our that both QNAP and Netgear use LIO Kernel Target in their larger
|
||
|
|
devices - hence the VMware certification. In any case, Red Hat are
|
||
|
|
behind it, although I think they are working on a fork of at least the
|
||
|
|
CLI, so I think success is assured there. That solves the problem of
|
||
|
|
block storage, be it iSCSI, Fibre-Channel, FCoE, Infiniband or even USB.
|
||
|
|
|
||
|
|
Another important building block in an enterprise storage system is some
|
||
|
|
way of distributing the data for both redunancy and performance. Marin
|
||
|
|
mentions [Ceph](https://ceph.com/) which is an excellent system.
|
||
|
|
Personally I would put my money on [GlusterFS](https://www.gluster.org/)
|
||
|
|
though. I have had slightly better performance from it. Red Hat bought
|
||
|
|
Gluster about a year ago, and have put some serious development effort
|
||
|
|
into it. As well as POSIX access via Fuse, it has Object storage for use
|
||
|
|
with OpenStack, a native Qemu connector is coming in the next versions.
|
||
|
|
Hadoop can also access it directly. There is also a very good Puppet
|
||
|
|
module for it, which gets around one of Martin's critisms of Ceph.
|
||
|
|
|
||
|
|
Which brings me nicely to managing this theoretical system. Embedding
|
||
|
|
Puppet in this sort of solution would also make sense. There will be
|
||
|
|
need to a way of keep config sync'ed on all the nodes (I mentioned that
|
||
|
|
this disruptive product will be scale-out didn't I? NO? OK, it will be
|
||
|
|
-prediction for the day). Puppet does this already very well, so why
|
||
|
|
re-invent the wheel.
|
||
|
|
|
||
|
|
All this can sit on top of Btrfs allowing each node to have up to 16
|
||
|
|
exabytes of local storage. For now I am not convinced by it, at least on
|
||
|
|
RHEL 6 as I have seen numerous kernel panics, nor did I have a huge
|
||
|
|
amount of joy on Fedora 17, but there is no doubt that it will get
|
||
|
|
there. Alternatively, there is always the combination of XFS and LVM.
|
||
|
|
XFS is getting on a bit now, but it has been revived by Red Hat in
|
||
|
|
recent years and it is a proven performer with plenty of life left in it
|
||
|
|
yet.
|
||
|
|
|
||
|
|
After all that, who do I think is ripe to do some serious disrupting in
|
||
|
|
the storage market? Who will "Do a Red Hat" as Martin puts it? Simple:
|
||
|
|
it will be Red Hat! Look at the best of breed tools at every level of
|
||
|
|
the storage stack on Linux and you will find it is either from Red Hat
|
||
|
|
(Gluster) or they are heavily involved (LIO target). They have the
|
||
|
|
resources and the market/mind share to do it. Also they have a long
|
||
|
|
history of working with and feeding back to the community, so the
|
||
|
|
fortuitous circle will continue.
|