Usability of OCUM in ... not so complex ... NAS environment - vFilers, DR, CIFS, NFS

[Harry_Redl]

Hello all,

we have in the middle of project implementation for the customer and we thought we can use OCUM for the monitoring/maintenance/configuration here ...

Well - I have mixed feelings now - OCUM has A LOT of interesting features - but there is always a catch which results in using OCUM AND another tool (or interface) to do the job.

So far we need to use of 6 them (if the customer does not accept CLI-only management) - OCUM/DFM/NMC, SystemManager, Qtree_Quota_Manager and CLI

I hope it is just me (but I am afraid that it is not the case here .... atleast not in all cases below)

Consider yourself:

1) Configuration management (configuration settings deployment)

Works great - I have several configuration files for both filers and vfilers - attached to groups accordingly - like a charm.

There are options to be set and files to be distributed - but not /etc/hosts - why? There was a requirement for this two years ago (atleast) - no response I know of.

2) vFiler management

When creating your own vFiler, you can choose either "manual" resource assignment or use a template. Using both methods, you do not have any control over location of root volume.

Using manual approach, your CIFS can only be set up in workgroup mode. Using template mode you can set up the AD authentication - but if your "Computers" OU is not accessible (you do not have rights for it), then no luck here ...

3) vFiler DR

well - if there is no vFilerDR plugin, then you are stuck with CLI only for vFiler DR (I LOVE CLI, but you cannot give this to the customer as the only and recommended solution)

So +100points to the creators of the plugin and shame on official release not supporting this.

I know it is far above the original goal of the plugin but if it adds few other functions, it can easily replace the rest of OCUM features for vFilers.

4) resizing volumes in vFilers

Using ResourcePools, DataSets, Provisioning Policies etc. I am able to resize the storage - but the actual sizes do not refresh well (especially on DR vFilers) not mentioning problems

with conformancy - DR vFiler is down ... well ... it is expected, but customer does not want to see red signs in the status ....

5) qtree quotas

No support at all? There is a great tool Qtree_Quota_Manager - but again - it is a standalone application not integrated in the OCUM ....

6) CIFS shares special attributes (widelinks, accessbasedenum....)

Do not think it is there - back to the CLI!

Can continue this way for hours .....

Is there ANY tool which can do all the stuff above? If I am wrong and this can be done with OCUM - show me, I will gladly admit being wrong here.

Jindrich

[thomas_glodde]

hey,

yes, there are certain limitations in OCUM, dont expect them to be fixed as 5.2 seems to be the last version for 7-mode ontap. Next generation OCUM 6 will basicly be a restart for C-Mode.

To close your gaps, give WorkFlow Automation Framework (WFA) a try, it is not as "gui doable" as OCUM but lets you automate your tasks way better as it uses the ontap api.

[REGIS_GARRUCHET]

Hi,

Just a few answers about what I know:

3/

IMHO, OCUM should integrate vfiler DR which is a great feature, but I'm pretty sure, it would be a lot easier for OCUM developpers  if vfiler was able to create a vfiler DR with a different name than the original name  (it's just a hostanme, so it would change nothing important for most configurations).

vfiler DR is a great feature but it creates 2 objects in DFM with the same name and restore features in NMC don't love that since it's ambiguous.

In some environments where DR and backups are essential, I prefer not to use vfiler DR, so I had to find some workarounds to be able to keep all protection features of OCUM and have a simple failover.

     So I create a dataset where I put only the vfiler root volume (but no vfiler attached to the dataset,because to be able to keep the root volume in it).

     And I create some other dataset (attached to the vfiler) for data volumes and use a DR mirror policy (or DR mirror then backup for instance).

     So when I need to do a failover DR, I just have to click on failover for the datasets of the vfiler, which takes seconds. Then you can script the recreation of the DR vfiler with a single command so you get the original configuration back (even with complex cifs options).

The advantage is that even with failover, backup features are still available and fully integrated and when failing back, I don't have to modify/reinitialize relationships  (a resync is sufficient). When using vfiler DR, it is a lot more complicated to keep backups working when switching to DR controller.

The issue is that the failback process is much more complex using OCUM since it can not be done in NMC GUI but only with DFM CLI.

4/ Since you use vfiler DR, I guess snapmirror are configured using snapmirror.conf and you have to resize detsination volumes manually, so Protection and Provisioning of secondary volumes is not really managed by  OCUM. In that case, OCUM can show only status that was on last polling. It is not refreshed instantaneously.

5/ Qtree quotas are managed in OCUM when provisioning qtrees in the dataset. You can edit qtree size in the provisioning tab (Ocum then modifies the quotas files in the vfiler if the dataset is associated with a vfiler). If you do that, then the volume is adjusted automatically so all qtrees fit in the volume.

6/ agree

,