Configuring online array support using Array Policy Module (APM)
Array Policy Module (APM)


The APM framework was introduced in Volume Manager 4.0 release. The 4.0 release brought about a major change in DMP architecture - the introduction of APM. As the name suggests, the Array Policy Module (APM) is specific to an array type and defines the policies for an array type. Analogous to its Array Support Library (ASL) counterpart in user space which enables the DDL to identify the array completely, the APM enables DMP kernel to perform array specific operations such as failover, NDU (Non-Disruptive Upgrade), STPG (Set Target Port Groups) and even an I/O policy.

The APM makes it possible for DMP to dynamically add kernel support for an array. The support for enabling an APM is completely online and does not require a reboot. An APM is essentially a dynamically loadable kernel module that is validated and loaded by DMP whenever DMP detects the array type support exported by that APM. In other words, the DDL recognises a disk array and its type using the ASL and, DMP uses the array type to identify a matching APM. Once the matching APM is located, the APM is loaded into DMP kernel dynamically as part of device configuration. Moreover, a single APM can support multiple array types. As an example, the CLARiiON APM supports CLR-A/P and CLR-A/PF array types in a single file.

The upgrade of an APM is also online and does not require the system reboot. Using the vxdmpadm CLI, an administrator can seamlessly upgrade an APM by installing the APM package that contains the APM binary and a key, analogous to ASL.

DMP solicits the services of an APM for all device related operations. For example, when a new device is configured into DMP, a callout happens into the APM and the new device becomes known to APM. Similarly, the callout happens into the APM when the state of a disk or a path changes. DMP also consults an APM to know of device states explicitly when device specific conditions occur. For example, if an array storage processor (SP) is undergoing a firmware upgrade, then DMP consults the corresponding APM to know the state of paths that accessible through the SP. In any case, once a callout happens and the control is transferred to an APM, the APM is free to do whatever device specific operations it wants to do. For instance, the APM may query the SP using array specific SCSI commands to find out the status of the firmware upgrade and notify DMP accordingly. Based on the response from APM, DMP may decide to delay the I/O, try an alternate path, or initiate failover.

To cater to most of the commonly used arrays, such as A/A, A/P, A/A-A, the DMP supplies default APM versions. The default APMs are capable of handling the generic services requested by DMP. However, if advanced features of an array, such as SP firmware upgrade, are to be used, then the APM is a necessity and must be installed in production environments.

In the next article, I shall touch upon the various I/O policies in DMP.

- Ameya P. Usgaonkar

1 Comment
Dear Sir,

I just went through your articles on DMP and found them of great use. I was however looking for an article on the various I/O policies present in DMP as that's an area of interest for me.
At the end of the article "Configuring online array support using Array Policy Module", you have written that you'll touch upon the various I/O policies in DMP in your next article. I would be grateful if you could provide me a reference to that article.

Thanks and Regards,

Mohit Vohra