StarBlog » solaris

Doing iSCSI targets on ZFS

Stargazer — Thu, 07 Jan 2010 06:51:48 +0000

As ZFS did quite well here – even after messing around with disks, I decided to give it another try. This time I am out to use its features on other systems. But to do so, I need to share it. As I am running virtual machines, it would be nice to have iSCSI shares to (ab)use. So let’s do it by starting the service:

# svcadm enable iscsitgt

As my Solaris install is still quite fresh I got a spare disk in it. It should carry my iscsi pool which I will just call ‘iscsistore’. Keeping it on a separate disk allows me to export it independently. So here we go:

# zpool create iscsistore c0t1d0

If you think that I have to mess around with dd now to write containers, you’re wrong. ZFS does this for us elegantly:

# zfs create -s -V 10gb iscsistore/zvol

Now the iSCSI shares:

# zfs set shareiscsi=on iscsistore/zvol

We check:

# iscsitadm list target -v

And that’s it. We’re ready to roll. Simple and easy. Simply ZFS.

Copyright © 2010
Please note that this feed is for private use only. All other usage, including the distribution or reproduction of multiple copies, performance or otherwise use in a public way of the images or text require the authorization of the author.
(digitalfingerprint: 0f46ca51d0fa4e6588e24f0bf2b80fed)

Disk failure and ZFS

Stargazer — Mon, 04 Jan 2010 00:41:42 +0000

ZFS is a beautiful filesystem – even in case of hardware failures, as it was build to deal with them. Allow me to demonstrate a defective disk on a Raid-Z1 pool. As long as only one disk breaks down, it is still functional – even while rebuilding.

To do the recovery, we need to locate the bad disk, which happens by typing ‘zpool status -x’:

  pool: MyPool
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
   see: http://www.sun.com/msg/ZFS-8000-2Q
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        Ahsay       DEGRADED     0     0     0
          raidz1    DEGRADED     0     0     0
            c1t0d5  ONLINE       0     0     0
            c1t0d6  ONLINE       0     0     0
            c1t0d7  UNAVAIL      0     0     0  cannot open
            c1t0d8  ONLINE       0     0     0

errors: No known data errors

The defective disk is c1t0d7. If the disk isn’t damaged, you can try to bring it back online using the command ‘zpool online ‘. In our case it would be ‘zpool online MyPool c1t0d7′

If this works, anything is fine again, but if you need to put the disk at another LUN, it gets a new ID. In that case you need to use ‘zpool replace [disk]‘ – the latter parameter is the new place of the disk. As I just overwrote the disk using dd, it stays at the same place, so ‘zpool replace MyPool c1t0d7′ is sufficient to integrate it back into the pool and it starts to rebuild:

pool: MyPool
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
 scrub: resilver in progress for 0h0m, 0.00% done, 517h14m to go
config:

        NAME              STATE     READ WRITE CKSUM
        Ahsay             DEGRADED     0     0     0
          raidz1          DEGRADED     0     0     0
            c1t0d5        ONLINE       0     0     0
            c1t0d6        ONLINE       0     0     0
            replacing     DEGRADED     0     0     7
              c1t0d7s0/o  FAULTED      0     0     0  corrupted data
              c1t0d7      ONLINE       0     0     0  3.54M resilvered
            c1t0d8        ONLINE       0     0     0

errors: No known data errors

After the rebuild, the so called ‘resilvering’ completed, the topic is history and we are done with it: short and sweet. In my opinion it’s even a little too easy to be true, as the whole system could stay online and working all the time.

My first glance at OpenSolaris

Stargazer — Wed, 23 Dec 2009 17:50:19 +0000

Today I was having my first glance at OpenSolaris. Getting the ISO burned, booting the LiveCD and all this didn’t take long and the system was booted, welcoming me with a Gnome Desktop environment – which I personally dislike for several reasons – but at least it is something to work with. And don’t forget: Solaris is the system offering ZFS underneath, which should be worth a look. So I clicked the install icon on the desktop and waited for the process to complete.

As the system finally rebooted, it was up and running. It seemed to me, like I could start working and so I fired up a browser and – had a network issue on screen. It looks like something went definitively wrong.

As an old Linux guy, I changed to the shell environment and checked the network card: cable attached, link up, ip address set up, gateway and nameserver are looking fine. So where’s the problem?

To make sure it isn’t the DNS server, I tried to ping its IP and it replied. Even nslookup delivered a fine result – but the system refused to do so. As I am on a Unix system here, there is no reason to feel lost at that point, but I did until I remembered the nsswitch.conf file which defines the way lookups are handled:

passwd:files
shadow:files
group:files
hosts: files
bootparams:files
ethers:files
netmasks:files
networks:files
protocols:files
rpc:files
services:files
automount:files
aliases:files

The problem was found in the line saying ‘hosts: files’ as it defines that no DNS server is queried for resolving hostnames. So changing it to ‘hosts: files dns’ did the trick and I am finally online.