ESS Shark Maintenance -- Question about it.

ESS Shark Maintenance -- Question about it.

Post by btn » Thu, 22 Aug 2002 21:34:03



Hi all,

I have a question about the maintenance on the shark (microcode
update, etc)
I know I can either disable the ports on my Fabric director while the
CE is doing the microcode upgrade on the shark or I could run the
datapath command with the offline option on the servers.

My question: Is this really necessary? If I have multiple Fibers on my
server, I imagine I may see link errors in the error log but I should
not have to do anything else while they do the concurrent upgrade. Is
this true?

Thanks in advance,

BTNA

 
 
 

ESS Shark Maintenance -- Question about it.

Post by Clive Spark » Fri, 23 Aug 2002 17:37:39



> Hi all,

> I have a question about the maintenance on the shark (microcode
> update, etc)
> I know I can either disable the ports on my Fabric director while the
> CE is doing the microcode upgrade on the shark or I could run the
> datapath command with the offline option on the servers.

> My question: Is this really necessary? If I have multiple Fibers on my
> server, I imagine I may see link errors in the error log but I should
> not have to do anything else while they do the concurrent upgrade. Is
> this true?

> Thanks in advance,

> BTNA

A lot depends on the version of SDD you have installed on the AIX
host, some of the earlier versions had problems with the path timeout.

Also be aware that you may require an outage of the FC adapter(s) on
the AIX host to install firmware as a co-req of the ESS upgrade, and
that there may also be co-req upgrades required for device drivers,
SDD, ibm2105cli, ESS utils and PTFs.

--
Regards,
Clive

 
 
 

ESS Shark Maintenance -- Question about it.

Post by Alvin Li » Fri, 23 Aug 2002 21:46:25



> Hi all,

> I have a question about the maintenance on the shark (microcode
> update, etc)
> I know I can either disable the ports on my Fabric director while the
> CE is doing the microcode upgrade on the shark or I could run the
> datapath command with the offline option on the servers.

> My question: Is this really necessary? If I have multiple Fibers on my
> server, I imagine I may see link errors in the error log but I should
> not have to do anything else while they do the concurrent upgrade. Is
> this true?

> Thanks in advance,

> BTNA

Recently, we had the CE do the concurrent LIC upgrade to 1.5.1.19.
Please keep in mind that we have dpo 1.2 on our servers (yes I know
that's ancient, we have plans to migrate to the latest sdd).  Our
nodes have multiple fibers/switches/etc.

A few of our vpaths 'dissappeared', much to my consternation.
Fortunately (for me), they all reappeared after a reboot.  But when
you have 40 nodes, reboots bite.

If you have the latest SDD you'll probably be ok.  I'm sure someone
else has done the concurrent LIC upgrade without any problems.

Now, my question is: has anyone done the conversion from dpo to sdd?
How was that?  All your hdisks mapped successfully to vpaths?

Cheers,
Alvin Liau

 
 
 

ESS Shark Maintenance -- Question about it.

Post by Dan Fost » Fri, 23 Aug 2002 22:54:18




>Recently, we had the CE do the concurrent LIC upgrade to 1.5.1.19.
>Please keep in mind that we have dpo 1.2 on our servers (yes I know
>that's ancient, we have plans to migrate to the latest sdd).  Our
>nodes have multiple fibers/switches/etc.

We've got a simple case -- multiple paths from servers to the Shark
via FC-AL but no switches. All hosts are AIX 4.3.3 at same revs, and
no SCSI for attachments anywhere. (We originally used SCSI but locking
was so much faster with FC-AL that it helped cut our HACMP failover
times...not to mention easier cabling and whatnot.)

Quote:>A few of our vpaths 'dissappeared', much to my consternation.
>Fortunately (for me), they all reappeared after a reboot.  But when
>you have 40 nodes, reboots bite.

:)

Quote:>Now, my question is: has anyone done the conversion from dpo to sdd?
>How was that?  All your hdisks mapped successfully to vpaths?

Just did that... process we used was:

1. Draft step by step plan and test on test boxes, finalize
2. Schedule downtime and arrange for CE to come on-site
3. On day of maint, CE started work -- total of 7 hours for the LIC upgrade
   and CE would not need to start disabling paths until about 3 hours into it.
4. We upgraded OS on servers, upgraded apps, removed all 2105 hdisks/vpaths
   and the dpo pseudodevice. (removal required to uninstall dpo!)
5. Uninstalled old v1.2 DPO driver
6. Installed new v1.3 SDD driver
7. Rebooted each server, one by one.
8. After they came up, hopped on, did 'lspv', 'lsvpcfg', 'datapath query
   device' to verify state and correct mapping.
9. Had to do 'hd2vp <ESS VG>' for each ESS VG hooked up to system. No big deal.
10. When CE was ready to take down an host bay, I disabled one path on each
    server (as appropriate) corresponding to the host bay, then told CE to
    proceed. After CE finished, I re-enabled, verified state, took down the
    next set of paths for next HB, told CE to proceed, etc.

That was all that we had to do.

It works ok if you have less than about 4-6 servers... if above that,
I would have split it into two separate maints -- one to upgrade systems
first and one to upgrade ESS once all systems upgraded.

I combined the two in a single maint because these were the few hosts
that I had great difficulty in scheduling a downtime for (once a year
is about all I get to do it!). I had already done the other hosts prior.

Did everything in a specific order in order to satisfy each step's prereqs,
and tested it all beforehand. So actual work went well.

The actual LIC upgrade process was transparent to us. The big trick is to
make sure the system is at correct revs (OS, 2105 drivers, SDD, etc) beforehand
so that it matches up with the new LIC code and will offer you least problems
or surprises that way.

SDD docs hints that any future upgrades to the SDD driver will be able to
be done without needing a reboot, so that's very hopeful. It's just when
going from 1.2 to 1.3 when a reboot is mandatory for various reasons.

I didn't have any problems with a transitional setup of 1.2 drivers on some
servers and 1.3 drivers on other servers; I just made sure to have them all
at 1.3 _before_ doing the ESS LIC upgrade.

That allowed me to schedule maints to upgrade individual servers in groups,
when I could, rather than needing to do all in one big swoop.

-Dan

 
 
 

1. Solaris on IBM ESS Shark

Does anyone have any sort of Solaris box attached to an ESS (Shark) SAN
via QLogic Fibre HBA cards?  I think I am having problems with setting up
load balancing/failover on them, and the documentation is sparse and
uninformative.  Anyone with this configuration that could post an example
of their /kernel/drv/sd.conf would have my eternal gratitude.

2. How to make an URL-tracker in sh

3. HBA Problems on RH Linux 7.2 on an IBM ESS (Shark) SAN

4. OS system

5. Uniquely identify ibm ess/shark, from an aix host

6. help ( korean users only )

7. ESS ES688 (Shark Multimedia MAKO) sound card

8. executing gzipped files?

9. Solaris 8 x QLA2200F x Shark (IBM ESS E20)

10. shark/ess/rs/6000 aix 5.1

11. Shark Multimedia ESS ES688 card w/Linux

12. IBM ESS (Shark) connectivity on a RedHat AS 2.1

13. Veritas 3.2 on IBM ESS Shark