Discovery of external relationships in ProtMgr

[blassen]

Hi,

I'm trying to understand how to improve on the discovery speed of newly added external relations.

To describe a little background ...

The customer in question is still doing the initial setup of the SM relation manually, as the ProtMgr can not handle the required naming convention

What happend though is that he had added new relations and these did not show up in the external relations. We than did a manual refresh on the scanning

on all the storagesystems in DFM.

The question is why this was not picked up automatically in a sensible timeframe (< 1 week)?

Is there a way to kick off the discovery again?

How/where can I find indicators to that something around the discovery is "stuck"?

[smoot]

This is not the expected behavior. DFM should discover new relationships in something like an hour or two.

Here are some things to check:

• Do you have working NDMP credentials for both storage systems? Run "dfm host diag" on both systems to check this.
• Are you having monitor issues? Reading SnapMirror status over SNMP has been a headache for a long time. Look in the dfmmonitor.log and smmon.log files  (in the log directory under the DFM install directory) to see if there are any messages about "corrupt SNMP tables". I believe the latest 4.0 patch has a fix to make this more reliable.

You can "kick" the monitor process by running "dfm host discover" for both the source and destination systems. If it took a week to discover the relationship, that won't help.

The other thing you can do is use the "dfdrm mirror initialize" command to create the relationship instead of the ONTAP CLI. This ensures the relationship is immediately inserted into the DFM database.

[adaikkap]

Hi

     Can you  check if dfm install dir has sufficent space, as we suspend monitroing if its less than 10 %, though the dfm service list may show the service is running.

[root@lnx ~]# dfm about
Version                          4.0 (4.0)
Serial Number                    1-XX-000001

Administrator Name               root
Host Name                        lnx
Host IP Address                  10.X.X.X
Host Full Name                   lnx186-118.lab.eng.btc.netapp.in
Operations Manager Node limit    999 (currently managing 10)
Provisioning Manager Node Limit  999 (currently managing 7)
Protection Manager Node Limit    999 (currently managing 6)
Operating System                 Red Hat Enterprise Linux AS release 4 (Nahant Update 5) 2.6.9-55.ELsmp x86_64
CPU Count                        2
System Memory                    3016 MB (load excluding cached memory: 61%)
Installation Directory           /opt/NTAPdfm
                                 101 GB free (69.9%)<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<Check if you see a error here.

Can you also check for the same using dfm diag | grep -i management.

If thats the case its better to setup alarms for management station events.

[root@lnx ~]# dfm eventtype list | grep -i "dfm.free.space"
management-station:enough-free-space          Normal       dfm.free.space
management-station:filesystem-filesize-limit-reached Error        dfm.free.space
management-station:not-enough-free-space      Error        dfm.free.space
[root@lnx ~]#

Reagrds

adai

[rshiva]

Hi,

Just a question out of curiosity, If Protection Manager cannot handle the naming convention, why create relationships outside Protection Manager? You can create the volumes manually and establish relationships manually through protection manager - That would would be far more simpler (just a suggestion).

Thanks and regards

Shiva Raja