Bruce Shaw wrote:
> I've been presented with the following scenario:
>
> - this is to be used primarily for ORACLE, including usage of ORACLE
> RMAN backups (to disk)
> - HP SAN (will NOT do JBOD)
> - 256 Gb disk available on high-speed Fibre Channel disk, currently on
> one LUN (1)
I presume this means a RAID array with nonvolatile write cache...
> - 256 Gb disk available on slower-speed SATA disk, currently on one LUN
> (2)
> - the mount point must be /ora01 to match legacy scripts
>
> First proposed solution:
>
> - create one zpool using FC disk to hold ORACLE apps and data
> - create one zpool using SATA disk to hold user directories, RMAN backup
> files, etc.
>
> I think this lacks vision.
>
> My proposal (which I'm rethinking and request suggestions):
>
> - create one zpool out of both LUNs, perhaps a zpool mirror
> - create /ora01, /ora_RMAN and /users zfs file systems underneath
>
> Hence:
>
> 1. My understanding of the situation is having a zpool on a single LUN
> precludes some ZFS technology such as self-healing, hence is not best
> practice. Right?
Not completely correct, nor incorrect. You could use copies with a single
LUN and be (mostly) protected against data loss. For important data and
when you have only one LUN (eg. arrays) using copies is a way to manage
your redundancy policies for each file system. In general, we like to see
ZFS have the ability to repair data.
> 2. My understanding of the situation is that ZFS is capable of
> detecting the fast FC disk vs. the slow SATA disk and arranging the
> underlying storage to best take advantage of this eg. shuffle the
> snapshots off to slower disk. Right?
No, not today.
> 3. Suggestions for zpool, zfs file system layout
I presume you'll use Solaris 10, so slogs are not available. Follow the
procedures for databases on ZFS at:
http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide
Prior to Solaris 10u5 (spring '08?) you will want to put your Oracle redo
log on a separate storage pool, preferrably on the fastest storage. But if
you follow this advice, then I wouldn't try to mirror the redo log pool with a
slow device because it is a write-mostly workload and will be sensitive to the
latency of commits to both sides of the mirror.
NB since you only have one LUN, the performance won't be great anyway. Or to
put this in perspective, competitive TPC-C benchmarks consume thousands of LUNs.
In that case, you might consider investing in memory for a larger SGA.
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
