Weblog entry #2 for cloakable
Does anyone think this is a good or a bad idea? Any suggestions? LVM? RAID? Filesystems?
Comments on this Entry
I think this is a great idea, and is something I've been wanting to mess around with for ages, I just can't quite afford the kit I'd like to use for a "production" setup. We have a DLink iSCSI SAN box at work, but it's really not quite as good as we'd hoped; don't get me wrong, it works nicely enough, but the management interface really sucks (java only front end, which is just plain nasty, and no snapshot facility for SAN-side backup).
What I'd like to get my hands on is some of the coraid AoE kit, which looks veeerrrrry nice indeed.
As for your questions: "LVM? RAID? Filesystems?", I'd have to say that if you go for dedicated hardware like that from coraid, the first two are probably best handled on that end, just providing block device targets. If you're going to be using normal generic PC hardware for the storage box, then I'd definitely go with some RAID and LVM -- all my servers have both, and all my desktops have at least the latter, I can't imagine running on normal hardware without them these days.
WRT the filesystem side of things though, it really depends on how you see yourself publishing the storage, whether redundancy/failover is a factor on the LAN side, and possibly other factors, such as how you manage authorisation/authentication on your LAN.
Something I've been meaning to tinker with for a while is GFS, which would allow multiple initiators to share the same SAN target at the block level, opening up the possibility for (potentially round-robin DNS) redundant access to SAN backed storage via AFS/NFS/CIFS etc.
If you're not really aiming that high and 1:1 storage<->server is OK in your enviroment, then any of the more usual FS suspects would be perfectly fine.
Cheers.:wq
[ Parent | Reply to this comment ]
I'll probably be using LVM2 on the initiator end - I discovered today you can make LVM2 provide the equivalent of RAID1 on a LV, using three physical disks - two for mirroring, one to keep a log of all changes so the mirror can be rebuilt after reboot.
Once the storage is pulled in on my SAN head, I'll be publishing it using SMB and NFS, so I'm currently tending towards JFS - it looks like it does reasonably at a wide range of tasks, has less overhead than ext3, and scales to some truly huge levels (max partition size of 32PiB, max file size of 4PiB).
On your idea for the redundant access to the SAN - have you thought of using heartbeat and fallover? I'm not likely to do that myself (trying to keep power costs down at home, so all the server backend stuff is VIA C7 currently).
[ Parent | Reply to this comment ]