One of the biggest problems we face today, as consolidation specialists, in storage, is attempting to actually push everything to a unified "one size fits all" standfast. In thinking about the concept of one-size-fits-all storage consolidation, I realised that ZFS is somewhat adept at this, given the intrinsic variable sector allocation that takes place seamlessly.

 In this tangent, I began trying to come up with a way to make better backup mechanisms from Mac OS X, Vista and "other" desktop operating systems, floating around my network. One of the biggest problems thus far with Time Machine and WHS (Windows Home Server) amongst other non-enterprise desktop OS's is that, they don't really play well with ZFS pools when shared across CIFS or Samba (or NFS), and oftentimes, it is quite hackish, just to get them to work at all. Those familiar with Time Machine architecture will know this string off by heart:

defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

 You are left, on the zpool, with what is known as a "sparse bundle", whereby you force Apple's Time Machine to recognise that an smb/NFS share is "legal" as a backup store, then it writes, what looks like an ever-expanding ISO file to the zpool. Unfortunately, no matter how you construe it, this won't work correctly with the TimeMachine interface, and you'll eventually get TM errors thrown as a result of the inability of the TM interface to read hard links from the ZFS pool, which is full of CoW soft links.

 So, I had a few thoughts about the use of iscsitadm and using proper iscsi exported LUN's back to the clients to achieve this task a little more succinctly.

  1. Installed OpenSolaris snv_103 on Intel Core2Duo Q6600 system

 2. Created a raidz1 array


bash 3.2# zpool create raidz1 backups c1t1d0 c1t1d1 c1t1d2

 3. Add some on the fly compression


zfs set compression=on backups

 4. Created iSCSI backing stores for separated backup volumes for each environment I wanted to cater for:


bash-3.2# zfs create -s -V 100GB backups/zebra_osx_backup
bash-3.2# zfs create -s -V 100GB backups/zebra_linux_backup
bash-3.2# zfs create -s -V 250GB backups/zebra_windows_backup

 Next, they needed to be shared out:


bash-3.2# zfs set shareiscsi=on backups/zebra_osx_backup
bash-3.2# zfs set shareiscsi=on backups/zebra_linux_backup
bash-3.2# zfs set shareiscsi=on backups/zebra_windows_backup

 5. At this point, it would be wise to check the LUN mapping information:


bash-3.2# iscsitadm list target
Target: backups/zebra_osx_backup
    iSCSI Name: iqn.1986-03.com.sun:02:b32135fe-29fe-ce68-a3de-83bd0ec088b1
    Connections: 0

Target: backups/zebra_linux_backup
    iSCSI Name: iqn.1986-03.com.sun:02:42859bd6-2b40-6b7c-beeb-a3d0a2be647e
    Connections: 0

Target: backups/zebra_windows_backup
    iSCSI Name: iqn.1986-03.com.sun:02:f6fcb58a-b3ac-4d09-f473-b62b6126adcc
    Connections: 0

 6. Mac OS X has some problems talking iSCSI without a few modifications. A non-product documented plist needs to be added, to make any initiator of any use to us. As follows, from /Library/Preferences/iSCSIconfig.plst:


	Manually Added Targets

	Portals

			IPSec ESP Mode
			Normal
			IPSec IKE Mode
			Normal
			IPSec PFS Mode
			0
			Portal Name
			192.168.0.8
			Portal Port
			3260
			Use Data Digest
			0
			Use Header Digest
			0
			Use IPSec
			0

 So, Mac OS X now understands iSCSI, but we'll need an initiator daemon!

 7. I found a wonderful FREE iscsi-initiator from globalSAN Inc, for Mac OS X. Once installed, I directed it to look for iSCSI targets at the IP address of the Solaris host:

zfsinteg1.png

 8. Once this is dealt with, you can then take a look in disk utility, to make the LUN act as real HFS+, just as Apple would prefer it:

zfsinteg2.png

 At this point, one should check if Time Machine actually works:

zfsinteg3.png

 Indeed, it appears to. Let's check the navigation GUI Apple provide:

zfsinteg4.png

 The same can be said for Windows Vista. We can make it behave just like any other disk internally to the system, with all the same behavioural patterns of NTFS, albeit, atop a ZFS zvol. We need to simply point the inbuilt Vista iSCSI initiator at the OpenSolaris host and discover targets.

 Finally, import it using the disk management utility that Windows offers, and format as a normal NTFS volume. Enjoy.

last modified by admin on 2009/10/26 12:17
Collectives
Project


© Sun Microsystems Inc. 2009
XWiki Enterprise 1.8.2.19075 - Documentation
Terms Of Use | Privacy | Trademarks | Copyright Policy | Site Guidelines | Site map | Help
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Use.