Active IQ Unified Manager Discussions
Active IQ Unified Manager Discussions
Currently the customer's DFM server is running extremely slowly on Windows 32-bit with only 4 GB of RAM. Many Snapmanager products are in use, including SME, SMSQL and SMO.
I think I need to do the following:
1) migrate the DFM server to windows 64-bit with much more memory (I'm thinking 16GB).
2) upgrade DFM from 4.0.2 to 5.1.
So the components are:
olddfm.local
newdfm.local
I think the steps I'll need to follow are:
1) back up the existing 4.0.2 DB.
2) stand up the new server (newdfm.local)
3) remove the old server (olddfm.local) from the domain
4) join the new server to the domain as olddfm.local
5) install 5.1 and restore/recover the DB from the backup I made in step 1).
I'm particularly worried about losing the existing backups/datasets. Is this the right approach?
Solved! See The Solution
Hi Mathew,
Currently the customer's DFM server is running extremely slowly on Windows 32-bit with only 4 GB of RAM. Many Snapmanager products are in use, including SME, SMSQL and SMO.
Can you tell us how many SnapManagers ? The SnapManager datasets are little heavier compared to the normal dataset and puts load on the dfm server.
1) migrate the DFM server to windows 64-bit with much more memory (I'm thinking 16GB).
Given that you already have quite few dataset, pls increase the memory further to 24 GB or some thing. As compared to 4.x which was a 32 bit application 5.x being a 64bit application will give better performance as it scales with the hardware.
2) upgrade DFM from 4.0.2 to 5.1.
Given that you have lot of SnapManager I am sure you have quite a lot of mark-deleted objects, I recommend you to run the dfm purge too and upgrade or upgrade and run the dfm purge tool. This way in one maintenance window you will be able to do both, as the purge tool requires downtime.
Here is the link to the purge tool
ToolChest Link: Utility Toolchest.
KB Article link:link
Video Link: DFM Purge Tool: How to Video
I think the steps I'll need to follow are:
1) back up the existing 4.0.2 DB.
2) stand up the new server (newdfm.local)
3) remove the old server (olddfm.local) from the domain
4) join the new server to the domain as olddfm.local
5) install 5.1 and restore/recover the DB from the backup I made in step
I would probably do it this way to reduce the impact or downtime to backup/Schedule
BTW if you have perf advisor enabled you may see some sluggishness initially after upgrade to 5.1. As we purge all the stale perf data due to clones created by SnapManager and later in a week or 2's time you will see a marked performance improvement.
I'm particularly worried about losing the existing backups/datasets. Is this the right approach?
Since you are doing a restore of the database you will not loose any backups or datasets. What you are doing is perfectly correct and right approach.
Regards
adai
Hi Mathew,
Currently the customer's DFM server is running extremely slowly on Windows 32-bit with only 4 GB of RAM. Many Snapmanager products are in use, including SME, SMSQL and SMO.
Can you tell us how many SnapManagers ? The SnapManager datasets are little heavier compared to the normal dataset and puts load on the dfm server.
1) migrate the DFM server to windows 64-bit with much more memory (I'm thinking 16GB).
Given that you already have quite few dataset, pls increase the memory further to 24 GB or some thing. As compared to 4.x which was a 32 bit application 5.x being a 64bit application will give better performance as it scales with the hardware.
2) upgrade DFM from 4.0.2 to 5.1.
Given that you have lot of SnapManager I am sure you have quite a lot of mark-deleted objects, I recommend you to run the dfm purge too and upgrade or upgrade and run the dfm purge tool. This way in one maintenance window you will be able to do both, as the purge tool requires downtime.
Here is the link to the purge tool
ToolChest Link: Utility Toolchest.
KB Article link:link
Video Link: DFM Purge Tool: How to Video
I think the steps I'll need to follow are:
1) back up the existing 4.0.2 DB.
2) stand up the new server (newdfm.local)
3) remove the old server (olddfm.local) from the domain
4) join the new server to the domain as olddfm.local
5) install 5.1 and restore/recover the DB from the backup I made in step
I would probably do it this way to reduce the impact or downtime to backup/Schedule
BTW if you have perf advisor enabled you may see some sluggishness initially after upgrade to 5.1. As we purge all the stale perf data due to clones created by SnapManager and later in a week or 2's time you will see a marked performance improvement.
I'm particularly worried about losing the existing backups/datasets. Is this the right approach?
Since you are doing a restore of the database you will not loose any backups or datasets. What you are doing is perfectly correct and right approach.
Regards
adai
Fantastic. Thanks!
Adai,
This environment has 11 datasets involving SMO, SME and SMSQL. Is that a lot? I'm thinking about running the Purge Tool now as the DFM server in question is very slow. To the point that SME backups sometimes timeout in attempting to get DFM to update their application datasets.
Hi Matthew,
When you said many I mistook it for 100+. 11 is not at all a big number or lot for DFM as well. In fact I would suggest you to run the purge too couple of days after you upgrade to 5.1 for the following reason. Starting 5.0 we turned the options of jobsPurgeOlder than from OFF to 90 day. This will purge any protection jobs older than 90 day. In order to reclaim/de-fragment the data a db reload and unload is required, even purge utility also requires the same. So the purge tool couple of days after 5.1 will upgrade will give you maximum benefit in minimum down time.
Regards
adai
Adai,
We just ran dfmpurge report and came up with the following:
I'd like to run the purge before doing the upgrade as it will take a long time to procure a new server and we are experiencing problems with SME/PM snapvault updates.
I'm a little confused by the 100% number. In the case of LUN paths, does that mean 100% of our LUN paths older than 3 days are marked to be deleted?
Hi Matty,
I'm a little confused by the 100% number. In the case of LUN paths, does that mean 100% of our LUN paths older than 3 days are marked to be deleted?
It means that all mark-deleted lun are older than 3 days. Or in other words 100% of the lun were mark-deleted by dfm monitor are older than 3 days.
BTW pls take a database backup before the purge. Also I strongly recommend you to read the KB article
Regards
adai