I appreciate the summary of how HDS works -- it's nice to have a little background on other vendors stuff, you never know what you'll be working with tomorrow...
Just to return the favor a bit, EMC Clariions can act just as you've stated here (LUN affinity); it's a selectable mode. The model I described (explicit) is recommended by EMC when Veritas or PowerPath are in use because of exactly the issues you mentioned -- the I/O simply cannot work on the other path so the LUN's don't end up bouncing back and forth (at, as you said, a huge performance penalty). We've seen lots of problems with this on HP-UX using the native logical volume manager -- particularly using the "pvmove" command...that can bring an entire array to it's knees with a massive trespass storm. The only solution we've found is to purchase PowerPath from EMC and set the system to explicit mode (though I suppose buying Veritas for HP-UX might work as well since it has the ASL/APM pieces that understand the array). Cheers! - Mike.Myers <at> nwdc.net -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Keating Sent: Wednesday, September 05, 2007 6:28 AM To: Darren Dunham; Veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] Drive type unknown Solaris 10 The OP indicated he's using WMS100. HDS modular arrays will allow the disk to be seen from either controller(service processor). >From what I've read in this thread, the Clariion requires a host request via the failover path to "switch" the LUN ownership, which would explain why the secondary controller would advertise the disk to the host as "unknown". I don't know the Clariion well, so excuse me if it behaves the same as below and the result seen is merely a function of VxVM. The HDS arrays aren't quite the same, in that they are not purely "active/passive", but rather "active/active **with LUN affinity**". What this means is that while the primary controller has exclusive control of the LUN, any request for the disk can been serviced via either controller, at any time, and the disks are FULLY visiable/available to the host via either controller at anytime. However, if you access the disk via the secondary controller, the secondary controller acts as a proxy and passes the IO over to the primary controller via the array's backplane (this is known an a LUN trespass) to service the request. The primary controller then returns the response to the secondary controller to forward back to the host. If the host maintains constant IO to a LUN via the LUN's non-owning controller for a dterminate amount of time, the array will transfer ownership of the LUN to the seoncadry controller. There is a HUGE performance penalty associated with operating in this state, particularly if the LUN belongs to a RAIDset where all the other LUNs on that RAIDset are owned by the other controller. This causes no end of grief with multipath management software that doesn't explicitly understand HDS' "LUN affinity" model. HDS tags "disks" with the appropriate metadata so that the multipath software can interpret which device is the proper one to communicate with. This is probably handled by the VRTSHDS-DF600-apm & VRTSHDS-DF600-asl packages the OP posted. So....all this to say that if the disks are showing up as "unknown", then this must be a specific "obscurity" laid over the disks by VxVM, since the HDS array will advertise the disk properly via ALL available paths. Paul -- > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Darren Dunham > Sent: September 4, 2007 5:59 PM > To: Veritas-vx@mailman.eng.auburn.edu > Subject: Re: [Veritas-vx] Drive type unknown Solaris 10 > > > > Does this make the 'format' command output more of an > aesthetic 'issue'. A red herring, in other words? > > The 'format' command is trying to read the disk label to present the > information in it to you in the list. > > If the label can't be read, you'll get the 'drive type unknown' > messages. 'format' is trying to read every path, valid or not. > 'vxdisk' will instead understand the topology and only try to read > through primary paths unless a failure is detected. > > -- > Darren Dunham > [EMAIL PROTECTED] > Senior Technical Consultant TAOS > http://www.taos.com/ > Got some Dr Pepper? San Francisco, > CA bay area > < This line left intentionally blank to confuse you. > > _______________________________________________ > Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx > ==================================================================================== La version française suit le texte anglais. ------------------------------------------------------------------------------------ This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. ------------------------------------------------------------------------------------ Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu. _______________________________________________ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx _______________________________________________ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
