Re: [Networker] Balancing load between storage nodes

Hi Jim,

Before you give up on the "one path to the device down either HBA"setup, have a look at my post (below) from January. On Solaris it'ssimple to create locally named /dev/whatever devices, which you can thensoft link to whichever REAL device you want the data to go to. In yourcase I'd recommend something like:


# Traffic down HBA0
ln -s /dev/rmt/0cbn /dev/JB1/Drive1
ln -s /dev/rmt/1cbn /dev/JB1/Drive2
....
ln -s /dev/rmt/4cbn /dev/JB1/Drive5

# Traffic down HBA1
ln -s /dev/rmt/15cbn /dev/JB1/Drive6
ln -s /dev/rmt/16cbn /dev/JB1/Drive7
.....

This setup also means you don't have to re-install (jbconfig) yourjukebox if your devices get re-ordered by a "reboot -- -r" : just pointthe soft links to the correct devices, and keep going.


HTH.
Will

Jim Ruskowsky wrote:

Thank you Prasad and everyone else who responded.
I have taken half of my clients and switched the order for Storage NodeAffinity.
(I am grateful for "nsradmin -i" for such a task)
Having two paths was set up because the paths are there, so why not havesomedegree of failover, but seeing how much trouble it is causing, I may endup
just assigning the drives to one or the other.
My "load balancing" wasn't meant to sent data to a single drive down twopathslike a disk operation, but to balance the drives as a whole between thetwoavailable paths in a dynamic way. I may try to change the order I listthe drivesin the jukebox config before abandoning the whole idea. i.e. half thedriveswould get listed with their path down fibre-channel-A first, the otherhalf wouldget their path down fibre-channel-B listed first. It is kind of a shameto have adata path available and not be able to take advantage of it in the case of
failure of the other path.
Prasad Chalikonda <prasadchalikonda AT yahoo DOT com> wrote on 05/08/200602:42:09 PM:

Hi Balki,

I was given a tip a couple of years ago which has proved fantastic fordealing with situations like this.

You can call the Tape Devices at the Solaris level anything you like(they're just links down into the /devices tree). So, our Networkerserver is configured with devices called:

/dev/UOL/CMRdrive1
/dev/UOL/CMRdrive2
/dev/UOL/CMRdrive3
/dev/UOL/CMRdrive....

/dev/UOL/HMRdrive1
/dev/UOL/HMRdrive2
/dev/UOL/HMRdrive3
/dev/UOL/HMRdrive....

Where CMR and HMR designate 2 different tape libraries, and "drive1"designates the drive number within the library.

The joy of configuring Networker this way is that WHEN your tape deviceschange Solaris name (/dev/rmt/2cbn becomes /dev/rmt/20cbn), you can justupdate some soft links, and not have to touch Networker!

server:ksh:# (11411) ls -l /dev/UOL
total 28

lrwxrwxrwx 1 root other 13 Sep 1 16:01 CMRdrive1 ->/dev/rmt/0cbnlrwxrwxrwx 1 root other 13 Sep 1 16:01 CMRdrive2 ->/dev/rmt/1cbnlrwxrwxrwx 1 root other 13 Sep 1 16:10 CMRdrive3 ->/dev/rmt/2cbnlrwxrwxrwx 1 root other 13 Sep 1 16:10 CMRdrive4 ->/dev/rmt/3cbnlrwxrwxrwx 1 root other 13 Sep 1 16:11 CMRdrive5 ->/dev/rmt/4cbnlrwxrwxrwx 1 root other 13 Sep 1 16:11 CMRdrive6 ->/dev/rmt/5cbnlrwxrwxrwx 1 root other 13 Sep 1 16:11 CMRdrive7 ->/dev/rmt/6cbnlrwxrwxrwx 1 root other 14 Sep 1 16:13 HMRdrive1 ->/dev/rmt/21cbnlrwxrwxrwx 1 root other 14 Sep 1 16:13 HMRdrive2 ->/dev/rmt/22cbnlrwxrwxrwx 1 root other 14 Sep 1 16:14 HMRdrive3 ->/dev/rmt/23cbnlrwxrwxrwx 1 root other 14 Sep 1 16:14 HMRdrive4 ->/dev/rmt/24cbnlrwxrwxrwx 1 root other 14 Sep 1 16:14 HMRdrive5 ->/dev/rmt/25cbnlrwxrwxrwx 1 root other 14 Sep 1 16:14 HMRdrive6 ->/dev/rmt/26cbnlrwxrwxrwx 1 root other 14 Sep 1 16:14 HMRdrive7 ->/dev/rmt/27cbn

server:ksh:# (11412)

This is also useful if you've got access to your tape drives throughmultiple HBA's, and wish to direct the IO for a specific tape drive overa specific HBA. You just change the link to point to the underlying tapedrive on the second HBA.

We've got 3 Solaris servers sharing 14 devices, and this naming schemeis wonderful for un-confusing things.


HTH
Will

Jim,

First off, I'd recommend a bit of redesign. Any reason
you have twopaths to each drive? Tape drives don't act like disks.Having two pathswon't load balance I/O. Additionally, it will cause
issues.

After you have configured just 1 path to each tape
drive, you controlwhich Storage Node a client is backed up to, amongother things, withwhat is called - Storage Node Affinity. It is aresource in the Clientset up. If left at default, that particular client isbacked up by theNSR Server (Master). To force a client to go to aStorage Node, put thatname up first, and in case SN fails, it will go to the
NSR Server.


HTH
Prasad.

Jim Ruskowsky wrote:
Hello list

Maybe somebody can offer some advice on the
following situation.
The setup....

We have 10 tape drives in a single library attached
to a fibre switch.
We have two networker servers (master and storage
node) attached to that
same switch - each server has two paths to that same
switch.
The fabric is configured so that each tape drive can
be seen on both paths
on each networker server.  We have dynamic drive
sharing licensed for all
10 drives.

So for example, drive #0 has four distinct paths
according to networker
       /dev/rmt/0cbn   (master server, first fibre
channel)
       /dev/rmt/10cbn  (master server, second fibre
channel)
       rd=jcnetworker2:/dev/rmt/0cbn   (storage
node, first fibre
channel)
       rd=jcnetworker2:/dev/rmt/10cbn  (storage
node, second fibre
channel)

The tape pool "DAILY" is set up as default with no
specific devices
checked off (so all drives should be used)

The problem....

When a savegroup runs, the server only uses the
drives attached to the
master server - ignoring the existence of the
storage node. I ended up
trying to write to 10 LTO3 drives down a single
fibre channel. What is
the best way to load balance between all my paths.
I've tried
specifically checking off specific paths to devices
in the tape pool
setup, but then it just picks a path to the master
server and ignores the
rest.

Thanks for any help.

Jim




Jefferies archives and reviews outgoing and incoming
e-mail.  It may be produced at the request of
regulators or in connection with civil litigation.
Jefferies accepts no liability for any errors or
omissions arising as a result of  transmission. Use by
other than intended recipients is prohibited.
To sign off this list, send email to
listserv AT listserv.temple DOT edu and type "signoff
networker" in the
body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any
problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at
http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection aroundhttp://mail.yahoo.com
Jefferies archives and reviews outgoing and incoming e-mail. It may be produced at the request of regulators or in connection with civil litigation.Jefferies accepts no liability for any errors or omissions arising as a result of transmission. Use by other than intended recipients is prohibited.
To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu 
if you have any problems
wit this list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER



--


w.parsons AT leeds.ac DOT uk
UNIX Support
Information Systems Services
The University of Leeds
+44 113 343 5670

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu 
if you have any problems
wit this list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER