PowerPath License Missing in EMC

Hi Christopher,

As you said, even I installed the license later on it was working on basic failover mode.

You may see the logs below that one of the SPs were unactive because of unlicenced configuration.

root@vs03a>powermt display dev=all

Pseudo name=emcpower1a

CLARiiON ID=CK200085101987 [~physical]

Logical device ID=60060160DA1023005848FE560A1BE311 [VSDB_DATA]

state=alive; policy=BasicFailover; priority=0; queued-IOs=0;

Owner: default=SP B, current=SP B       Array failover mode: 4

==============================================================================

--------------- Host ---------------   - Stor -   -- I/O Path --  -- Stats ---

###  HW Path               I/O Paths    Interf.   Mode    State   Q-IOs Errors

==============================================================================

3075 pci@0/pci@0/pci@8/pci@0/pci@a/SUNW,qlc@0/fp@0,0 c2t0d5s0  SP B1     active  alive       0      0

3074 pci@0/pci@0/pci@8/pci@0/pci@2/SUNW,qlc@0/fp@0,0 c3t0d5s0  SP A0     unlic   alive       0      0

I think, with such a configuration you can not access both of the SPs at the same time. If the link towards active one fails, it is failed over to the other one.

With your suggestion my concern is answered. See the log below that after policy change device accesses are well.

root@vs03a>powermt display dev=all

Pseudo name=emcpower1a

CLARiiON ID=CK200085101987 [~physical]

Logical device ID=60060160DA1023005848FE560A1BE311 [VSDB_DATA]

state=alive; policy=CLAROpt; priority=0; queued-IOs=0;

Owner: default=SP B, current=SP B       Array failover mode: 4

==============================================================================

--------------- Host ---------------   - Stor -   -- I/O Path --  -- Stats ---

###  HW Path               I/O Paths    Interf.   Mode    State   Q-IOs Errors

==============================================================================

3075 pci@0/pci@0/pci@8/pci@0/pci@a/SUNW,qlc@0/fp@0,0 c2t0d5s0  SP B1     active  alive       0      0

3074 pci@0/pci@0/pci@8/pci@0/pci@2/SUNW,qlc@0/fp@0,0 c3t0d5s0  SP A0     active  alive       0      0

Besides I saw no difference in hba mode before and after changing policy. Anyway no information is written about policy on those outputs. This would maybe related with single hba usage over each SP (one for SPA one for SPB we use).

Thanks much on these.

I have some more queries on EMC. I would be appreciated if answered.

Each time I reboot server, I see some failure logs related to EMC Monitor. Besides no problem observed so far with functionality:

Sep 18 16:49:09 vs03a emc_monitor[1220]: [ID 702911 user.error] EMC Monitor internal error, exiting:

It this log normal to have? On the other hand when I checked, I see the following with emc monitor service;

root@vs03a>svcs |grep -i emc

legacy_run     Sep_18   lrc:/etc/rc3_d/S78emcp_mond

legacy_run     Sep_18   lrc:/etc/rc3_d/S97emcmonitor

online         Sep_18   svc:/system/emcpower/powerstartup:default

online         Sep_18   svc:/system/emcpower/powershift:default

No related process on the server.

root@vs03a>ps -ef |grep -i emc

    root  7350  5717   0 13:12:06 pts/1       0:00 grep -i emc

Thanks,

sinanatan wrote: root@vs03a>powermt display dev=all Pseudo name=emcpower1a CLARiiON ID=CK200085101987 [~physical] Logical device ID=60060160DA1023005848FE560A1BE311 [VSDB_DATA] state=alive; policy=BasicFailover; priority=0; queued-IOs=0; Owner: default=SP B, current=SP B      Array failover mode: 4 ============================================================================== --------------- Host ---------------  - Stor -  -- I/O Path --  -- Stats --- ###  HW Path              I/O Paths    Interf.  Mode    State  Q-IOs Errors ============================================================================== 3075 pci@0/pci@0/pci@8/pci@0/pci@a/SUNW,qlc@0/fp@0,0 c2t0d5s0  SP B1    active  alive      0      0 3074 pci@0/pci@0/pci@8/pci@0/pci@2/SUNW,qlc@0/fp@0,0 c3t0d5s0  SP A0    unlic  alive      0      0 I think, with such a configuration you can not access both of the SPs at the same time. If the link towards active one fails, it is failed over to the other one.

Let's dissect this a bit and see how "lucky" you were, from the perspective of automatic fault handling of PowerPath, that an SP did not fail or rebooted for instance during a FLARE code upgrade.  This is why if you are going to do direct connection of hosts (versus via FC/iSCSI/FCoE switches) you really need a license for PowerPath (or of course could use the OS's native MPIO solution).  With ALUA which you have configured (Array failover mode: 4) it would only have protected you from a loss of all front-end paths to the owning SP which would route to/from the current owner of the LUN via the non-optimal path which is through the peer SP and the PCI-E connection (CMI) between each SP.  Well... up to 128K I/O's at which point it will do an implicit trespass.  Anyways...

Firstly, I will assume that you have a direct connection to the SP's from each HBA versus a switched environment.  Reason I have come to that conclusion of course is seeing each HBA connected to a single port as represented by the ctds (controller:target:device:slice) references.

c2 (of c2t0d5s0) = one HBA (or port in consideration maybe of a single multi-port HBA)

c3 (of c3t0d5s0) = another HBA (or port)

You even acknowledged this as intentional:

This would maybe related with single hba usage over each SP (one for SPA one for SPB we use).

On the other hand if you have a switched environment, then you should absolutely zone each HBA to a port on SP A and B (for a total of 4 unique paths).

I think, with such a configuration you can not access both of the SPs at the same time. If the link towards active one fails, it is failed over to the other one.

You are only partially correct.  For reference, I will repost the 4 bullet points regarding an unlicensed installation of PowerPath:

1) It will only actively use a single path to the current owner of the LUN even if for a single HBA you happen to have more than one path to each SP

2) Will only provide backend failover in case of an SP failure for instance (will trespass a LUN as needed - takes in consideration ALUA also)

3) Will NOT provide HBA failover (in consideration of more than one HBA)

4) As a consequence of the above, you therefore lose any (dynamic) load-balancing across multiple paths (via single or multiple HBA's to each LUN)

What you are seeing is the fact that BasicFailover only uses a single HBA.  Let's say you zoned each HBA to a port on SP A and B in a switched environment.

1) For *both* paths (SP A and B) assigned to c2, you would see active/alive

2) For *both* paths (SP A and B) assigned to c3, you would see unlic/alive

Now let us compare in the direct connection configuration (2 paths) that you have currently and the proposed switched configuration (4 paths) in the case of an SP failure (and not just the front-end paths to an SP being unavailable):

Since from your output SP B is the current owner of this LUN, assume SP B becomes faulted and requires an (explicit) trespass:

1) DAS: (2 paths total) With an unlicensed installation of PowerPath, as noted in bullet point 3 above, it will *not* provide (automatic) HBA failover from the path associated with c2 to the path associated with c3.  Again you would need a full (multi-pathing) PowerPath license or of course forgo PowerPath and use the native MPIO solution of Solaris instead.

2) (iSCSI/FC/FCoE)-SW: (4 paths total) Since c2 would also have a path to SP A, after the LUN trespass, I/O would resume down its peer path

Could you repost the new question in a separate thread (also in the same PowerPath community)?  Sorry to ask, but it is worthy of a separate discussion.  Before I knew it, I certainly wrote more than I had originally expected and don't want it to get lost at the bottom.

Thanks again for your cooperation.

The host will still be able to communicate to the other SP as long as the licensed HBA on the host is zoned to both hosts. If you have PowerPath licensed it will failover to the other HBA. If you don't have PowerPath licensed it will not failover to the other HBA. If you have both HBAs zoned to A and B the trespass LUN scenario will not cause the host to lose access to the LUN since the licensed HBA on the host can see A and B paths.

Hi Christopher,

I've opened a seperate discussion.

I am clear with multi hba access towards an SP but a bit confused with the sample you've given in my scenario. If you can clarify some more, I would be appreciated.

There are several cases in fact with failover scenarios;

- SP problem (means SP is down, not functioning well)

- Connectivity is down between SP and host (HBA/Connectivity problem etc)

As I know if the SP is down LUNs owned by it are trespassed to other SP and advertised to hosts. So if you are connected to other SP you would not lose access to LUNs (But I am confused with unlicensed scenario). Is host able to communicate with unlicensed SP link (in normal conditions or when active SP path is down)? If not, this would mean a downtime with storage access on the host.

In case hba connection is down towards primary SP, I expect my host to communicate to LUNs owned by that SP over other SP (as you commented pci link between these SPs). Here it is also important if my host is able to communicate with the SP link marked as unlicensed.

In fact, in default I access both of the SPs at the same time as some of the LUNs are owned by SPA and some of them by SPB.

Note: My architecture is Host A -> 1 hba towards SPA, 1 hba towards SPB

                                       Host B -> 1 hba towards SPA, 1 hba towards SPB

These hosts are cluster and handlin same kind of traffic.

These are direct point to point connections. No FCoE etc, I'm clear that these kind of solutions (FCoE etc..) doubles the pathes between hosts and storage.

Thanks,