Wow, the blog entry says pretty explicitly what I wish EMC or Sun would have told us months ago:
"The APM, analogous to user land counterpart ASL, was tailored to handle array specific problems such as initiating failover and supporting array specific technologies such as NDU (Non-Disruptive Upgrade) from EMC." I read that to say, without an APM loaded, NDU is NOT supported (NDU is EMC's way of doing firmware updates while the system is up). Thanks a lot for these excellent references! - Mike Myers, mike.myers <at> nwdc.net -----Original Message----- From: Thomas Cornely [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 9:01 PM To: Myers, Mike; veritas-vx@mailman.eng.auburn.edu Subject: RE: [Veritas-vx] ASL, APM and EMC Clariions (oh my...) Hi Mike, Interesting... I had no idea this doc was there. :) Another good document if you're looking for insights on DMP is the "DMP 3.5/4.x whitepaper". It's a great doc on DMP's design pre-5.0 and pre-DMP Backport (4.0 MP4 on AIX, 4.1 MP2 on Solaris and 4.1 MP4 on Linux). You can get it at: http://eval.symantec.com/mktginfo/products/White_Papers/Storage_Server_M anagement/sf_dmp_wp.pdf Finally, you may want to check out the following URL for blogs and forums on Symantec products. There currently is one blog on DMP, and I know Ameya has a few more in the pipe, with a focus on ASL, APMs: http://www.symantec.com/enterprise/stn/index.jsp https://forums.symantec.com/syment/blog/article?blog.id=Ameyablog&messag e.id=2 Happy reading, Thomas PS: For other Storage Foundation whitepapers: http://www.symantec.com/enterprise/products/whitepapers.jsp?pcid=1020&pv id=203_1 > -----Original Message----- > From: Myers, Mike [mailto:[EMAIL PROTECTED] > Sent: Monday, April 02, 2007 10:25 AM > To: Thomas Cornely; veritas-vx@mailman.eng.auburn.edu > Subject: RE: [Veritas-vx] ASL, APM and EMC Clariions (oh my...) > > Thomas, > Thank you for the answers, this helped clarify the ASL and > APM roles for me a great deal. > > A support person at Sun also dug up this document which has > an excellent summary of their roles as well: > > http://eval.symantec.com/mktginfo/products/White_Papers/Storag > e_Server_M > anagement/sf_dmp_field_guide.doc > > It's certainly unclear to my why this is filed under > marketing info but oh well...at least it exists! > > Cheers, > - Mike Myers, mike.myers <at> nwdc.net > > -----Original Message----- > From: Thomas Cornely [mailto:[EMAIL PROTECTED] > Sent: Friday, March 30, 2007 12:06 PM > To: Myers, Mike; veritas-vx@mailman.eng.auburn.edu > Subject: RE: [Veritas-vx] ASL, APM and EMC Clariions (oh my...) > > Hi Mike, > > With the right ASL/APM, you indeed shouldn't have issues with > Clariion NDU. > Please see inline below for more details. > > Thanks, > > Thomas > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > Behalf Of Myers, > > Mike > > Sent: Wednesday, March 28, 2007 9:09 PM > > To: veritas-vx@mailman.eng.auburn.edu > > Subject: [Veritas-vx] ASL, APM and EMC Clariions (oh my...) > > > > So I've been doing some research on a few systems of ours > that didn't > > handle an EMC Clariion firmware update gracefully (path loss was > > passed up to the VxFS layer before DMP kicked in and failed over -- > > oops). We think the problem might be related to the ASL > being quite > > old so I've been doing a lot of digging into this area of Veritas > > which I've not delved into much before. It doesn't appear to be a > > very well documented area of the software. > > > > So a few specific questions if anyone can assist: > > > > * What's the difference between an Array Support Library > and a Array > > Policy Module? The Veritas support article on EMC > Clariions point to > > a tar ball that includes both (CLR-APM and > > DGC-Clar) > > [Thomas] ASL stands for 'Array Support Libray'. They allow > DMP to properly claim a device, identify what type of array > it sits in and basically tell DMP which sets of procedures to > use to manage the paths to that device. > > APM stands for 'Array Policy Module'. These are dynamically > loaded kernel modules that implement the sets of procedures > and commands that DMP must issue to an array to manage the > paths to it. The base DMP code comes with a set of default > APMs for Active/Active arrays or Active/Passive arrays. These > APMs are "generic" in nature. For arrays that are require > specific handling (and the Clariion is a perfect example of > that), DMP relies on array specific APMs that implement > procedures and commands that are specific to that array. > > > > > * Is there a command in Veritas to answer the question, > "What ASL is > > "controlling" device X?" The closest I've been able to > find is to run > > "vxdmpadm getsubpaths ctlr=X" on one of the devices: > > > > NAME STATE[A] PATH-TYPE[M] DMPNODENAME > > ENCLR-TYPE ENCLR-NAME ATTRS > > ============================================================== > > ========== > > ======== > > c5t50060163306036AFd2s2 ENABLED(A) PRIMARY EMC_CLARiiON0_0 > > EMC_CLARiiON EMC_CLARiiON0 - > > c5t50060163306036AFd1s2 ENABLED(A) SECONDARY EMC_CLARiiON0_1 > > EMC_CLARiiON EMC_CLARiiON0 - > > > > I think a better command to issue here would be: 'vxdmpadm > listenclosure all' because that will show which enclosures > DMP has identified and how it claimed them (from the > array_type column). Here's an example: > --- > $ vxdmpadm listenclosure all > ENCLR_NAME ENCLR_TYPE ENCLR_SNO STATUS > ARRAY_TYPE > ============================================================== > ========== > ==== > EMC0 EMC 940159 CONNECTED A/A > Disk Disk DISKS > CONNECTED Disk > EMC_CLARiiON0 EMC_CLARiiON APM00054800086 CONNECTED > CLR-A/PF > --- > > CLR-A/PF tells you that the Clariion was claimed with > 'explicit failover mode' (Clariion Failovermode 1). > A Clariion configured to Failovermode 2 would get claimed > with array_type 'CLR-A/P'. > > > * Why would the Clariion APM appear NOT to be in use? (maybe the > > answer to my first question will make this question moot): > > > > $ vxdmpadm listapm all > > Module Name APM Name APM Version Array Types > > State > > ============================================================== > > ========== > > ======== > > dmpaa dmpaa 1 A/A > > Active > > dmpap dmpap 1 A/P > > Active > > dmpap dmpap 1 A/P-C > > Active > > dmpapf dmpapf 1 A/PF-VERITAS > > Not-Active > > dmpapf dmpapf 1 A/PF-T3PLUS > > Not-Active > > dmpapg dmpapg 1 A/PG > > Not-Active > > dmpapg dmpapg 1 A/PG-C > > Not-Active > > dmpjbod dmpjbod 1 Disk > > Active > > dmpjbod dmpjbod 1 APdisk > > Active > > dmpCLARiiON dmpCLARiiON 1 CLR-A/P > > Not-Active > > dmpCLARiiON dmpCLARiiON 1 CLR-A/PF > > Not-Active > > > > * Veritas seems very confident in their documentation that > an ASL may > > be removed (and replaced) without impacting the controlled > devices. > > Has anyone on here done that to production systems? > > > > The ASL seems like a fairly integral piece of DMP to be > removed while > > I/O is traversing the DMP device. That said, my little bit > of testing > > seems to indicate that this is true. > > Is the ASL only consulted once per boot (or when vxdctl enable is > > run)? I guess I'm leading to the question of what does an ASL > > actually do? > > [Thomas] Yes, an ASL really gets used at device discovery, so > anytime vxdisk scandisk or vxdctl enable (more involved) gets > called. One the device is claimed, the ASL doesn't do > anything. The APM effectively takes over. > So you should have no problem updating an ASL online. > I would think updating an APM online should also work. The > commands that are specifically in the APM tend to relate to > path state management (i.e. how to trigger a LUN trespass, > what to do following an IO failure, how to interpret this > array specific sense data) and typically are not related to > IO load balancing. Support would know that. > > > I'm looking for something beyond, > > "It tells DMP which paths to use" -- it's obviously not involved in > > the minute-to-minute I/O operations. What sorts of things does it > > tell the DMP layer? How can you tell if it's working > correctly (short > > of an invasive test like pulling a fiber)... > > > > Thanks in advance for any info folks can provide! If there > is useful > > information sent off-list, I'll post a summary. > > > > Cheers, > > - Mike Myers, mike.myers <at> nwdc.net > > > > _______________________________________________ > > 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
