c0t0d0s0.org

The development team for iSER (iSCSI over RDMA over Infiniband) announced, that their prototype is up and running : [iser-dev] iSER prototype implementation is working!!!

Pheewww ... i´ve finalized my SamFS tutorial, a long text. SamFS is the hierarchical Storage Management Filesystem from sun. Several new concepts, so you have to explain some theory before getting to the shell:

• Part 1: Introduction.html
• Part 2: The theory of Hierarchical Storage Management
• Part 3: The Jargon of SamFS
• Part 4: Installation of the packages
• Part 5: Configuring a SamFS filesystem
• Part 6: Configuring disk archiving
• Part 7: Working with SamFS
• Part 8: Usecases and future directions
• Part 9: Conclusion

As usual: Have fun!

Now we´ve configured a file system and we set up the archiver for it. Now let´s use it.

Okay, now we can configure our first filesystem with SamFS.

It´s quite easy to install SamFS. It´s just installing two packages and answering some questions.

As usual, this technology has it´s own jargon. Thus i will start to define the most important words at first.

I think, i should start with the theory of Hierarchical Storage Management(HSM). The technology of managing data and their position on different media isn´t really a widespread feature for most adminstrators. Thus this introduction will be a quite long one.

Okay, this is tutorial isn´t really about feature of Solaris itself. But the feature of this tutorial it´s deeply coupled with Solaris. Thus you can view it as an optional part of Solaris. This time i will dig into the installation and configuration of SamFS. But a warning, SamFS is a feature monster. This tutorial is equivalent to put your toes in the Atlantic ocean, but when i saw the annoucement of the open-sourcing of SamFS i thought, it´s time to write this document. In addition to that, it was a nice way to make a reality check on a thought game, i´ve made some months ago.

I wrote about iSCSI quite often in the last time. But how can you use it in Solaris. I wrote a short introduction about the usage of the iSCSI implementation of Solaris:

• Part 1: Introduction
• Part 2: Basic iSCSI
• Part 3: Bidirectional authenticated iSCSI
• Part 4: Alternative backing store
• Part 5: Conclusion

And as usual: Have fun while trying iSCSI on Solaris!

Okay, this was a quick introduction to the actual implementation of iSCSI on Solaris. The future will bring changes to the implementation of the iSCSI target feature but new possibilities as well. iSCSI will be an part of the COMSTAR framework in the future besides of an SAS target or an FC target.

Albeit it´s very easy to use iSCSI in conjunction with ZFS emulated volumes it doesn´t have to be this way. You can use different kinds of backing store for iSCSI

At first I will show you, how to do a really simple iSCSI configuration. This is without any authentication. Thus everybody can connect to the iSCSI targets on the system. But this is sufficient for a test. And it´s this is better for having a quick success.

With more and more available bandwidth it gets more and more feasible to use only a single network to transmit data in the datacenter. Networking can get really complex when you have to implement two networks. For example for Ethernet and one for FC. It´s getting more complex and expensive, as FC network are mostly optical ones and Ethernet is a copper network in most datacenters.

I had an idea to vastly reduce the network load for iSCSI harddisks while waiting for the water to boil for my first tea. There are two new features in development for ZFS: L2ARC and Separated ZIL. L2ARC enables ZFS to use a disc as a second level cache (thus speeding up reads). The Separated ZIL enables ZFS to use a disc as to use a dedicated disc for the ZFS Intent Log (thus speeding up writes). Both features were designed with solid state disks in mind to augment "rotating rust" hard disks. But this features are not limited to this high end task.

Think about the following usecase: A server has in most cases some local boot disks even when you use iSCSI or FC. From a 146 GB disc you need only roundabout 20 GB (2x 7.5 for OS incl. Live Upgrade Partition and 5 GB for swap) or so. Thus you have 126 GB left. Okay, let´s assume, that you have two X4500 exporting zvols with iSCSI.

You have another machine in your network. You create an mirrored ZFS pool out of the remote iSCSI volume. But now the both new features come into the game. We augment this iSCSI volume with a local separated ZIL and a local L2ARC. With the first one, you keep the log writes from the network and with the local L2ARC you get an really huge local cache without sacrifying precious memory resources. Many read/write requests stay local to the system and you can vastly reduce the load to the network. Thus