Wiki code for ZFS iSCSI pool integration

Hide Line numbers
1: 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.
2: 
3:  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:
4: 
5: {{{
6: defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1
7: }}}
8: 
9:  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.
10: 
11:  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.
12: 
13:  1. Installed OpenSolaris snv_103 on Intel Core2Duo Q6600 system
14: 
15:  2. Created a raidz1 array
16: 
17: {{{
18: 
19: bash 3.2# zpool create raidz1 backups c1t1d0 c1t1d1 c1t1d2
20: 
21: }}}
22: 
23:  3. Add some on the fly compression
24: 
25: {{{
26: 
27: zfs set compression=on backups
28: 
29: }}}
30: 
31:  4. Created iSCSI backing stores for separated backup volumes for each environment I wanted to cater for:
32: 
33: {{{
34: 
35: bash-3.2# zfs create -s -V 100GB backups/zebra_osx_backup
36: bash-3.2# zfs create -s -V 100GB backups/zebra_linux_backup
37: bash-3.2# zfs create -s -V 250GB backups/zebra_windows_backup
38: 
39: }}}
40: 
41:  Next, they needed to be shared out:
42: 
43: {{{
44: 
45: bash-3.2# zfs set shareiscsi=on backups/zebra_osx_backup
46: bash-3.2# zfs set shareiscsi=on backups/zebra_linux_backup
47: bash-3.2# zfs set shareiscsi=on backups/zebra_windows_backup
48: 
49: }}}
50: 
51:  5. At this point, it would be wise to check the LUN mapping information:
52: 
53: {{{
54: 
55: bash-3.2# iscsitadm list target
56: Target: backups/zebra_osx_backup
57:     iSCSI Name: iqn.1986-03.com.sun:02:b32135fe-29fe-ce68-a3de-83bd0ec088b1
58:     Connections: 0
59: 
60: Target: backups/zebra_linux_backup
61:     iSCSI Name: iqn.1986-03.com.sun:02:42859bd6-2b40-6b7c-beeb-a3d0a2be647e
62:     Connections: 0
63: 
64: Target: backups/zebra_windows_backup
65:     iSCSI Name: iqn.1986-03.com.sun:02:f6fcb58a-b3ac-4d09-f473-b62b6126adcc
66:     Connections: 0
67: 
68: }}}
69: 
70:  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:
71: 
72: {{{
73: 
74: 	Manually Added Targets
75: 
76: 	Portals
77: 
78: 			IPSec ESP Mode
79: 			Normal
80: 			IPSec IKE Mode
81: 			Normal
82: 			IPSec PFS Mode
83: 			0
84: 			Portal Name
85: 			192.168.0.8
86: 			Portal Port
87: 			3260
88: 			Use Data Digest
89: 			0
90: 			Use Header Digest
91: 			0
92: 			Use IPSec
93: 			0
94: 
95: }}}
96: 
97:  So, Mac OS X now understands iSCSI, but we’ll need an initiator daemon!
98: 
99:  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:
100: 
101:  [[image:User Group qosug.files@zfsinteg1.png||alt="zfsinteg1.png"]]
102: 
103:  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:
104: 
105:  [[image:User Group qosug.files@zfsinteg2.png||alt="zfsinteg2.png"]]
106: 
107:  At this point, one should check if Time Machine actually works:
108: 
109:  [[image:User Group qosug.files@zfsinteg3.png||alt="zfsinteg3.png"]]
110: 
111:  Indeed, it appears to. Let’s check the navigation GUI Apple provide:
112: 
113:  [[image:User Group qosug.files@zfsinteg4.png||alt="zfsinteg4.png"]]
114: 
115:  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.
116: 
117:  Finally, import it using the disk management utility that Windows offers, and format as a normal NTFS volume. Enjoy.
OpenSolaris

Top Menu

Wiki code for ZFS iSCSI pool integration

Search

Collectives

Community Group

Project

User Group

Subsites

User Group qosug Pages
