On May 31, 2007, at 12:15 AM, Nathan Huisman wrote:
===== PROBLEM
To create a disk storage system that will act as an archive point for
user data (Non-recoverable data), and also act as a back end storage
unit for virtual machines at a block level.
<snip>
Here are some tips from me. I notice you mention iSCSI a lot so I'll
stick to that...
Q1: The best way to mirror in real time is to do it from the
consumers of the storage, ie, your iSCSI clients. Implement two
storage servers (say, two x4100s with attached disk) and put their
disk into zpools. The two servers do not have to know about each
other. Configure ZFS file systems identically on both and export them
to the client that'll use it. Use the software mirroring feature on
the client to mirror these iSCSI shares (eg: dynamic disks on
Windows, LVM on Linux, SVM on Solaris).
What this gives you are two storage servers (ZFS-backed, serving out
iSCSI shares) and the client(s) take a share from each and mirror
them... if one of the ZFS servers were to go kaput, the other is
still there actively taking in and serving data. From the client's
perspective, it'll just look like one side of the mirror went down
and after you get the downed ZFS server back up, you would initiate
normal mirror reattachment procedure on the client(s).
This will also allow you to patch your ZFS servers without downtime
incurred on your clients.
The disk storage on your two ZFS+iSCSI servers could be anything.
Given your budget and space needs, I would suggest looking at the
Apple Xserve RAID with 750GB drives. You're a .edu, so the price of
these things will likely please you (I just snapped up two of them at
my .edu for a really insane price).
Q2: The client will just see the iSCSI share as a raw block device.
Put your ext3/xfs/jfs on it as you please... to ZFS on the it is just
data. That's the only way you can use iSCSI, really.... it's block
level, remember. On ZFS, the iSCSI backing store is one large sparse
file.
Q3: See the zpool man page, specifically the 'zpool replace ...'
command.
Q4: Since (or if) you're doing iSCSI, ZFS snapshots will be of no
value to you since ZFS can't see into those iSCSI backing store
files. I'll assume that you have a backup system in place for your
existing infrastructure (Networker, NetBackup or what have you) so
back up the stuff from the *clients* and not the ZFS servers. Just
space the backup schedule out if you have multiple clients so that
the ZFS+iSCSI servers aren't overloaded with all its clients reading
data suddenly with backup time rolls around.
Q5: Sure, nothing would stop you from doing that sort of config, but
it's something that would make Rube Goldberg smile. Keep out any
unneeded complexity and condense the solution.
Excuse my ASCII art skills, but consider this:
[JBOD/ARRAY]---(fc)--->[ZFS/iSCSI server 1]---(iscsi share)-----
[Client ]
[mirroring the]
[JBOD/ARRAY]---(fc)--->[ZFS/iSCSI server 2]---(iscsi share)-----
[ two shares ]
Kill one of the JBODs or arrays, OR the ZFS+iSCSI servers, and your
clients are still in good shape as long as their software mirroring
facility behaves.
/dale
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
