Unisphere 9.x with VMAX 40k

Recently, I update Unisphere and Solutions Enabler to 9.0 for the VMAX 40k.  Unisphere 8.4 will not be supported after May 2020.  Few things are not supported for VMAX 40k in Unisphere 9.0.  Belows are the things I don't like about new Unisphere 9.

1. I cannot export list of luns in storage group.  I guess EMC wants customer to use ViPR SRM to run report (not sure if this is only applied to VMAX 40k)
2. No more provision template for VMAX 40k and that is not convenient.  
3. Cannot change FAST priority in the GUI any more for SG of VMAX40k
4. Heatmap is not shown in a single page.  

Heat Map in 8.4

Heat Map in 9.0

      5.   In Unisphere 8.4, if you want to delete meta members after dissolve a meta lun, you can select the option to delete meta members.  However, it will only delete meta head in Unisphere 9.  It will be fixed in Unisphere 9.1 according to support.  Because there is no more meta from VMAX, I suspect the developer forget about the VMAX 40k.    

6. There is a limitation with Unisphere 9.0.  Only the first 1024 luns will be shown.  You can use the filter to display the luns after the first 1024.  The filter for lun label does not work too well in 8.x.  However, once it is fixed in version 9, now, only the first 1024 luns will be shown.  See EMC kb Unisphere for PowerMax: Maximum viewable amount is 1024 volumes(000529643)

There was a bug in earlier version of Unisphere 8.x.  When you try to delete a meta lun under Virtual lun, it will crash the Unisphere GUI for VMAX 40k.  It is fixed in Unisphere 8.4.  Glad it is passed to Unisphere 9.0.  Also, if you try to create metalun from Unisphere, striped is populated auto and cannot be changed.  I have not tried to create concatenated lun with CLI in SE 9.0.

Just a reminder don't forget to change the smc password after installing Unisphere.

For VMAX 40k, you cannot change the Unisphere smc password running in SP.  So, make sure to restrict IP access to SP from the network. 

========================================================================
Just upgrade to Unisphere 9.1 (12/2019) 
It does fix the issue mentioned before for dissolve and delete meta luns.  However, it generates 3 new problems.

a) AD login does not work after upgrade.  (using local account at the moment)
b) Cannot customize performance alert for each thin pool / disk group.  (no workaround)
c) Dash Board reduces the overall health by 20 points because SSD pool is 95% full (recommendation  by vendor is to reserve only 1% of space given no lun is bounded / pinned to SSD and only thin provision is used).  This is not an issue.  Just ignore it. 

Hopefully, next patch fixes it. 

Also database in 9.1 is different.  Upgrade fails at database upgrade.  Since I ran all the monthly reports, I actually need to uninstall 9.1 and then install again in another folder.  So, it is a fresh installation for me.  
========================================================================

Update to Unisphere 9.1.0.20 (11/2020)  

AD login issue is still not resolved.  Still using local account.  

Alert customization for each Thin Pool / Disk Group seems fixed if I set it up in IE (won't work with Chrome).   

I doubt the last one mentioned before will be fixed.  Dash Board still reduce overall health by 20 points for SSD usage over 95%.  I will probably stay in this version until migration to PowerMax.  

AppSync login page won't load with 404 error

 After Windows patching and AppSync server reboot, the management page of AppSync won't load.  It only show the 404 error Not found.  Restart server makes no difference.  Check from support page and find the kb 501522  https://support.emc.com/kb/501522

I do see the three files with undeployed below.  So follow the kb and the issue is fixed.  

apollo.ear.undeployed

archway-ear.ear.undeployed

remotex.rar.undeployed

Below is kb501522 from EMC support site.  

Cause

This may be seen if the Appsync Server services are Started and Stopped in quick succession. There are a number of files, such as E:\EMC\AppSync\jboss\.\standalone\..\applications\apollo.ear which are deployed by the Appsync Server during startup. If the service is stopped before these files are fully deployed the Appsync Server may begin to throw this error.

When we check the location C:\EMC\AppSync\jboss\applications we should see the following 6 files in a healthy system: 

• Apollo.ear
• apollo.ear.deployed
• archway-ear.ear
• archway-ear.ear.deployed
• remotex.rar
• remotex.rar.deployed

When we check on a system showing the "Error 404 not found" error we should find some of these files marked as undeployed, eg "apollo.ear.undeployed ".

Workaround

In order to resolve this issue we have to get the Appsync Server service to deploy the .EAR files. Follow the procedure outlined below to accomplish this. 
When we find undeployed files in the C:\EMC\AppSync\jboss\applications folder perform below mentioned steps to resolve:

1. Stop all the services.
2. Take backup of the C:\EMC\AppSync\jboss\applications.
3. Rename Apollo.ear.undeployed to Apollo.ear.dodeploy.
4. Perform the same steps as step 3 in case any other EAR files are also shown as undeployed.
5. Start the services.
6. Check the status for .EAR files again at the location C:\EMC\AppSync\jboss\applications.

i. Apollo.ear

ii. apollo.ear.deployed

iii. archway-ear.ear

iv.archway-ear.ear.deployed

v.remotex.rar

vi.remotex.rar.deployed

7. Try to log in into appsync GUI after 5 minutes and you should be able to log in.

AppSync with VMAX 40k

AppSync 3.5 was installed couple years ago to protect our SQL application.  Basically, AppSync agent was installed in SQL cluster.  The SQL clusters were running as VMs and the databases were residing in RDM.

Kept getting VSS error that it takes more than 10s to create VSS.  That was what MS supported for VSS.  If it took more than 10s, the VSS creation step would fail.

Installed latest Solution Enabler 8.4.x.x available at the time and no change.  Since the array was VMAX 40k, DNS was not a factor.  Eventually, version Version 3.5.0.1_URM00111091_PRELIM_R2  fix the bug VSS 10s delay bug with VMAX 40k.

Couple things I don't like about the AppSync.
1)  Mounting and Dismounting SQL VMFS takes long time and does not work well.
2)  Need to reserve an extra copy of luns in the pool   
3)  If info is not sync, AppSync does not know what to do.  So, manually dismount copy from mount host will cause problem because AppSync does not know the luns are dismount.  Eventually, contacting support to clean up is required.

------------------------------------------------------------------------------------------------------------

Now, 3 yrs later, AppSync 3.9 was setup for proof of concept few months ago.  This time, we have SQL running in VMFS.  We encounter same issue as before.  Mounting copy to mount host is very slow and timeout.  Eventually, we keep our design for SQL as before in RDM.  Things are working smoothly with RDM as expected.   

We are still using the AppSync 3.5 now until we migrate to AppSync 3.9 next yr.  Recently, SQL team change the DB structures and instead of a few larger database, we have a lot of smaller database to be protected.  The AppSync host plugin service has memory leak problem.  So, we have to setup a process to bounce the service once every 3 days.  Hopefully, this won't happen in version 3.9.