Last week we discussed why you’d want to run an iSNS server to manage your iSCSI infrastructure. As promised, we will now get you started with the OpenSolaris iSNS server configuration.
Why Use Domains?
The main functionality we’re focusing on here is the ability to partition your iSNS clients into domains. This means that individual targets and initiators can be grouped together into a discovery domain, which enables them to “see” each other. Just like SAN zoning, this is essential to limiting the sheer number of devices seen, and to a certain extent ensuring security. The iSCSI protocol also supports authentication, but controlling which devices can pair eliminates the possibility of them communicating at all—another layer of security and manageability.
On the manageability front, there are three main reasons to partition your iSNS devices into discovery domains.
1. Spheres of Control
Instead of dedicating iSCSI storage devices per-IT group and sharing everything with all their servers, you can simply create an iSNS domain. By sharing only a portion of a device to the groups that need it, each storage device is more fully utilized, and of course, centrally managed from a single point of control.
VMware, Xen, and others operate beautifully with iSCSI. To implement live migrations and hot failover of virtual machines, every server in the cluster needs access to the iSCSI device a virtual machine is run from. The only way to accomplish this without iSNS and discovery domains is to have all servers use the “send targets” iSCSI discovery command. They will get a list of all iSCSI targets available on the server, but then so will other iSCSI initiators that use some of the other targets on that device. Ideally, each machine in a virtual machine cluster will discover all targets used by other cluster members, but nothing else. This is very easy to accomplish with a centrally managed iSNS server.
3. Server Isolation
At times, we may need to ensure that nothing but the designated initiator is able to discover a target. Even if it cannot login to the target because of authentication policies, the availability of the target may violate local security policies or jeopardize governmental security compliance. For those reasons, it is best to configure individual domains for your most sensitive servers, to ensure nothing but the intended parties can even attempt to authenticate.
Setting up the OpenSolaris iSNS Server
First things first; you need to install OpenSolaris and enable the iSNS server. Once OpenSolaris is installed, run the following command to enable the iSNS service:
svcadm enable isns_server
This will start the service and enable you to query it for information. Before you will see anything, you will have to register iSNS clients, which we will get to in a moment. First, we create discovery domains.
Actually, I’ve hidden one little detail. There is another organizational container in the OpenSolaris iSNS server: the discovery domain set. You can group together multiple domains into sets, which enables even more groupings to make management easier. Before we can do anything, the default discovery domain set needs to be enabled:
isnsadm enable-dd-set Default
To see which domain sets are configured, and whether or not they are enabled, run:
isnsadm list-dd-set -v DD Set name: Default State: Enabled DD Set name: Something_Else State: Enabled
Once a domain set is enabled, we can start creating discovery domains. Every discovery domain is created as a member of the Default domain set, which must then be moved to the desired domain set. If you plan to use more than one discovery domain set, we recommend you leave the Default set disabled, so that newly created discovery domains are not active until you move them.
To create a new discovery domain, run:
isnsadm create-dd _domain_name_
Next, move it to another domain set with:
isnsadm add-dd _domain_name_ -s _set_name_
You can then view which domains are a member of the set with:
isnsadm list-dd-set -v _domain_name_
Working With Clients
Next, we need to configure iSNS clients to register with the server. This involves configuring both targets and initiators. To keep this example as simple as possible, we’ll skip authentication and use both Solaris targets and initiators, but you surely won’t be as limited.
Configure the iSCSI target node to register with the iSNS server:
iscsitadm modify admin --isns-server _HOST_ --isns-access enable
We’ll also need to tell the initiators to use the iSNS server with the following commands:
iscsiadm add isns-server _HOST_ iscsiadm modify discovery --isns enable
Now, we should see these clients (by iSCSI Name) on the iSNS server. They, too, will be part of the Default iSNS discovery domain. Use the command
isnsadm list-node to display the clients and note the iSCSI Name.
To get them working, you will need to move each client into the same discovery domain. As you might have guessed by now, it’s as easy as:
isnsadm add-node -d _DOMAIN_ _iSCSI_NAME_
Ensure that everything is configured correctly by listing the nodes in the domain:
isnsadm list-dd -v _DOMAIN_
Congratulations! You can now see the targets on the machine you’ve configured to be the initiator, and connect as usual.
There is a lot more to configuring and managing the iSNS server, but this should get you on your way. Removing and moving nodes is just as intuitive as creating them was in the above example. Refer to the chapter 15 of the Devices and File Systems Sysadmin Guide at sun.com to get the full, glorious details.
Finally, there is also a GUI interface available for download on the OpenSolaris iSNS project Web page. We did not test it, but the Java GUI apparently allows you to easily manage many aspects of the iSNS server, including domain and node management.