UPDATE! The community will be go into read-only on April 19, 8am Pacific in preparation for migration on April 21. Read more.
UPDATE! The community will be go into read-only on April 19, 8am Pacific in preparation for migration on April 21.Read more.
Cadet 1st Class
Cadet 1st Class
303 views

Migrate to ZENworks 2020 Virtual Appliance - Best practice

Jump to solution

Hi,

we planning to migrate and use the the Virtual Appliance for ZENworks in the future.

Following environment we are running right now:

- 2 primary servers, same location
  - VMs running Windows 2019 Standard
  - ZENworks 2020 Update 1
- 1 database server
  - VM running CentOS 7
  - PostgreSQL 11.11

If we migrate to the appliance, what would be the best setup? Does it make sense to have a separate "content-repo" disk or is it "best practice" if we stick with the "vastorage" disk and just extend the disk if we need of more storage?

Database: Is it better to have this running embedded in the Virtual Appliance or have it running standalone?

The main goal for the migration is that we simplify our environment and that future updates/upgrades are easier to handle. Right now I am testing the Virtual Appliance in a test environment and upgrading from 2017 to 2020 works fine so far. 

Thank you for the tips in advance 🙂

Best regards,
Florian

1 Solution

Accepted Solutions
Micro Focus Expert
Micro Focus Expert

"The main goal for the migration is that we simplify our environment and that future updates/upgrades are easier to handle. '

Focusing on that statement.....

Database: Is it better to have this running embedded in the Virtual Appliance or have it running standalone?  Using the Integrated DB will remove a significant portion but not all DB administration from your plate.  Upgrades and required patching will likely be automated.  Some DB maintenance will be handled automatically.  Having an Internal DB will even help with Disaster Recovery.....The reason is that if you have to revert VM to an earlier snapshot, the CONTENT-REPO and DB will be in 100% synch.  If the DB and Primary are separate, then there could be a disconnect.

Of course, having an External DB may remove some risk.....It does not remove the "Hardware Failure Risk" or "OS ISSUE" since the  DB server is just as likely to have a "Hardware or OS" issue as a ZCM server.  However, a ZCM Primary could have ZCM Software issues where it simply began filling the disk for an unknown reason until there was no space left.  The ZCM primary could have a software issue that pegged the CPU to  100% cause the DB to be slow servicing the other primaries.  etc.. etc...

In this case, the DB server would be unaffected and able to service the second primary.   However, when you consider DR scenarios, increased DB administration requirements, etc...  I'm not really convinced that external would be significantly more reliable.  Generally, I recommend External because either it is needed for performance reasons or there is an existing DB server managed by a qualified DB Administrator who will use his professional skills to ensure the DB is maintained in tip-top condition.

Does it make sense to have a separate "content-repo" disk or is it "best practice" if we stick with the "vastorage" disk and just extend the disk if we need more storage?

I will again go back to your statement that you want to "Simplify".  Creating additional mount points adds points of failure and added complexity.  There have been cases where mount points were lost due to one software reason or another and had to be re-established.  Most of the time, I've seen them added because of the need for more space and the fear of the expansion going wrong.  The issue is, at some point, you will need to expand that mount or break up that mount into multiple mounts. 

If you are going to expand an existing disk....Make sure you have a test lab and do the process there first.  Make sure you backup the actual VMDK prior to expanding, since sometimes the expansion process can fail and corrupt the disk.  If you do not have a lab and cannot backup the VMDK, adding mount points may be safer, but I would never sleep well at night knowing I cannot make a hard backup of my VMDKs and I have no lab...

 

--
Please give a hearty thumbs up to any post you find helpful!
To find articles by Craig Wilson simply follow the link: Craig Wilson's Tips!

View solution in original post

6 Replies
Micro Focus Expert
Micro Focus Expert

I'm not sure if one is preferred more than the other vastorage vs a separate content repo. I would tend to stick with the defaults and use vastorage disk. I'd suggest making it large enough for current and future use. I can be enlarged in the future.

I might suggest waiting for 2020 Update 2, otherwise you're looking at migrating to appliances on 2021 Update 1 and then migrating the disks from those appliances to new appliances on 2020 Update 2. Unlike other minor updates in the past, Update 2 will have a new appliance. I prefer to minimize the number of moves myself.

Embedded DB is more for smaller device loads (looks at the docs for specifics). External/standalone is for bigger device loads. On the plus side if you have external/standalone, it's not tied down to a primary server and if a primary server goes down, it doesn't potentially take your DB with it and thus other primary servers can active and continue to work.

Just some of my thoughts.

0 Likes
Commodore
Commodore

It is always of good advice to use a separate disk for content.

As "migration" method i would do the following :

  1. add virtual appliance(s) to your zone as primary server(s)
  2. migrate CA role (certificate authority, usually hold by your 1st installed master server) to one of your new server, see documentation in BCP-DRP part
  3. wait for this information to propagate to all your clients devices
  4. finally remove your hold servers, one at a time

Didi I miss something ?

+---
“Everyone is ignorant. We’re simply not ignorant of the same things.”
+---
Don't forget to Like helpful posts and mark Solutions!
0 Likes
Micro Focus Expert
Micro Focus Expert

"The main goal for the migration is that we simplify our environment and that future updates/upgrades are easier to handle. '

Focusing on that statement.....

Database: Is it better to have this running embedded in the Virtual Appliance or have it running standalone?  Using the Integrated DB will remove a significant portion but not all DB administration from your plate.  Upgrades and required patching will likely be automated.  Some DB maintenance will be handled automatically.  Having an Internal DB will even help with Disaster Recovery.....The reason is that if you have to revert VM to an earlier snapshot, the CONTENT-REPO and DB will be in 100% synch.  If the DB and Primary are separate, then there could be a disconnect.

Of course, having an External DB may remove some risk.....It does not remove the "Hardware Failure Risk" or "OS ISSUE" since the  DB server is just as likely to have a "Hardware or OS" issue as a ZCM server.  However, a ZCM Primary could have ZCM Software issues where it simply began filling the disk for an unknown reason until there was no space left.  The ZCM primary could have a software issue that pegged the CPU to  100% cause the DB to be slow servicing the other primaries.  etc.. etc...

In this case, the DB server would be unaffected and able to service the second primary.   However, when you consider DR scenarios, increased DB administration requirements, etc...  I'm not really convinced that external would be significantly more reliable.  Generally, I recommend External because either it is needed for performance reasons or there is an existing DB server managed by a qualified DB Administrator who will use his professional skills to ensure the DB is maintained in tip-top condition.

Does it make sense to have a separate "content-repo" disk or is it "best practice" if we stick with the "vastorage" disk and just extend the disk if we need more storage?

I will again go back to your statement that you want to "Simplify".  Creating additional mount points adds points of failure and added complexity.  There have been cases where mount points were lost due to one software reason or another and had to be re-established.  Most of the time, I've seen them added because of the need for more space and the fear of the expansion going wrong.  The issue is, at some point, you will need to expand that mount or break up that mount into multiple mounts. 

If you are going to expand an existing disk....Make sure you have a test lab and do the process there first.  Make sure you backup the actual VMDK prior to expanding, since sometimes the expansion process can fail and corrupt the disk.  If you do not have a lab and cannot backup the VMDK, adding mount points may be safer, but I would never sleep well at night knowing I cannot make a hard backup of my VMDKs and I have no lab...

 

--
Please give a hearty thumbs up to any post you find helpful!
To find articles by Craig Wilson simply follow the link: Craig Wilson's Tips!

View solution in original post

Cadet 1st Class
Cadet 1st Class

Many thanks for the inputs! Really helpful.

I will continue my testing in my test lab with following setup for now:

- 2 primary servers
  - "vastorage" disk

- 1 database server
  - CentOS 7
  - PostgreSQL 11.x

The testing will also include every possible scenario. Like upgrading the database version and the whole OS. Because we need also to move from CentOS 7 to 8.  How it works to extending the disk etc.

Best regards,
Florian 

0 Likes
Cadet 1st Class
Cadet 1st Class

@strj500 : Do you know when ZENworks 2020 U2 will be released?

0 Likes
Micro Focus Expert
Micro Focus Expert

Not before June....

July most likely.....

Currently in Beta.....

--
Please give a hearty thumbs up to any post you find helpful!
To find articles by Craig Wilson simply follow the link: Craig Wilson's Tips!
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.