Thanks Will -
Thats a good suggestion to clean up the way things look.
Right now my device numbers (rmt0, rmt1, rmt2, etc) are in backwards
order of the order of devices in the jukebox. (drive0=rmt9, drive1=rmt8,
drive2=rmt7, etc)
This of course can lead to confusion. Your method maps the confusion to a
singe
out of the way place that is not visible in the legato screen.
Jim
Will Parsons <w.parsons AT leeds.ac DOT uk> wrote on 05/09/2006 04:10:53 AM:
> 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's
> simple to create locally named /dev/whatever devices, which you can then
> soft link to whichever REAL device you want the data to go to. In your
> case 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) your
> jukebox if your devices get re-ordered by a "reboot -- -r" : just point
> the 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 Node
> >Affinity.
> >(I am grateful for "nsradmin -i" for such a task)
> >
> >Having two paths was set up because the paths are there, so why not
have
> >some
> >degree of failover, but seeing how much trouble it is causing, I may
end
> >up
> >just assigning the drives to one or the other.
> >
> >My "load balancing" wasn't meant to sent data to a single drive down
two
> >paths
> >like a disk operation, but to balance the drives as a whole between the
> >two
> >available paths in a dynamic way. I may try to change the order I list
> >the drives
> >in the jukebox config before abandoning the whole idea. i.e. half the
> >drives
> >would get listed with their path down fibre-channel-A first, the other
> >half would
> >get their path down fibre-channel-B listed first. It is kind of a
shame
> >to have a
> >data 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/2006
> >02:42:09 PM:
> >
> >
> >
> Hi Balki,
> I was given a tip a couple of years ago which has proved fantastic for
> dealing 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 Networker
> server 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 devices
> change Solaris name (/dev/rmt/2cbn becomes /dev/rmt/20cbn), you can just
> update 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/0cbn
> lrwxrwxrwx 1 root other 13 Sep 1 16:01 CMRdrive2 ->
> /dev/rmt/1cbn
> lrwxrwxrwx 1 root other 13 Sep 1 16:10 CMRdrive3 ->
> /dev/rmt/2cbn
> lrwxrwxrwx 1 root other 13 Sep 1 16:10 CMRdrive4 ->
> /dev/rmt/3cbn
> lrwxrwxrwx 1 root other 13 Sep 1 16:11 CMRdrive5 ->
> /dev/rmt/4cbn
> lrwxrwxrwx 1 root other 13 Sep 1 16:11 CMRdrive6 ->
> /dev/rmt/5cbn
> lrwxrwxrwx 1 root other 13 Sep 1 16:11 CMRdrive7 ->
> /dev/rmt/6cbn
> lrwxrwxrwx 1 root other 14 Sep 1 16:13 HMRdrive1 ->
> /dev/rmt/21cbn
> lrwxrwxrwx 1 root other 14 Sep 1 16:13 HMRdrive2 ->
> /dev/rmt/22cbn
> lrwxrwxrwx 1 root other 14 Sep 1 16:14 HMRdrive3 ->
> /dev/rmt/23cbn
> lrwxrwxrwx 1 root other 14 Sep 1 16:14 HMRdrive4 ->
> /dev/rmt/24cbn
> lrwxrwxrwx 1 root other 14 Sep 1 16:14 HMRdrive5 ->
> /dev/rmt/25cbn
> lrwxrwxrwx 1 root other 14 Sep 1 16:14 HMRdrive6 ->
> /dev/rmt/26cbn
> lrwxrwxrwx 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 through
> multiple HBA's, and wish to direct the IO for a specific tape drive over
> a specific HBA. You just change the link to point to the underlying tape
> drive on the second HBA.
>
> We've got 3 Solaris servers sharing 14 devices, and this naming scheme
> is wonderful for un-confusing things.
>
> HTH
> Will
>
>
>
>
>
>
>
> >>Jim,
> >>
> >>First off, I'd recommend a bit of redesign. Any reason
> >>you have two
> >>paths to each drive? Tape drives don't act like disks.
> >>Having two paths
> >>won't load balance I/O. Additionally, it will cause
> >>issues.
> >>
> >>After you have configured just 1 path to each tape
> >>drive, you control
> >>which Storage Node a client is backed up to, among
> >>other things, with
> >>what is called - Storage Node Affinity. It is a
> >>resource in the Client
> >>set up. If left at default, that particular client is
> >>backed up by the
> >>NSR Server (Master). To force a client to go to a
> >>Storage Node, put that
> >>name 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 around
> >>http://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@listserv.
> temple.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
>
>
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
|
