Remediate remote hosts using central VUM
dave330i
Member Posts: 2,091 ■■■■■■■■■■
Ran into an interesting design problem at work. Design calls for a central vCenter to manage multiple remote site hosts. How do you go about remediating these remote hosts? There's a 1 to 1 relationship between vCenter and VUM. Pushing remediate package for each host across WAN seems extremely inefficient. I get the feeling if we deploy a repository at each remote site, VUM will pull the patch to central then push it out to remote site.
Anyone have a good solution? I think auto deploy with local TFTP server at each remote site will probably work, but statelessness of 5.0 auto deploy makes this a tough sell.
Anyone have a good solution? I think auto deploy with local TFTP server at each remote site will probably work, but statelessness of 5.0 auto deploy makes this a tough sell.
2018 Certification Goals: Maybe VMware Sales Cert
"Simplify, then add lightness" -Colin Chapman
"Simplify, then add lightness" -Colin Chapman
Comments
-
meadIT Member Posts: 581 ■■■■□□□□□□The update repository is designed for multiple vCenters to download updates from one place. It is inefficient to have to transfer that data multiple times, but that is just a design risk created by the requirement of having a central vCenter server. The patches shouldn't be too large if the updates are done on a regular basis. Upgrades (which require the complete install image) on the other hand could be an issue.
Off the top of my head, some workarounds could be A) a WAN optimization appliance that would cache the data on the remote site or stage the ISO for the upgrade at the remote site and then upgrade the hosts via their iLO or iDRAC, etc instead of VUM.CERTS: VCDX #110 / VCAP-DCA #500 (v5 & 4) / VCAP-DCD #10(v5 & 4) / VCP 5 & 4 / EMCISA / MCSE 2003 / MCTS: Vista / CCNA / CCENT / Security+ / Network+ / Project+ / CIW Database Design Specialist, Professional, Associate -
dave330i Member Posts: 2,091 ■■■■■■■■■■stage the ISO for the upgrade at the remote site and then upgrade the hosts via their iLO or iDRAC, etc instead of VUM.
Co-worker mentioned patch via CLI, so that's an option. Not sure why there's a 1 to 1 relationship between vCenter and VUM. Other appliances such as vDR can have many to 1 vCenter. Submitted a VMware feature request.2018 Certification Goals: Maybe VMware Sales Cert
"Simplify, then add lightness" -Colin Chapman -
blargoe Member Posts: 4,174 ■■■■■■■■■□The individual patches shouldn't be a problem over the WAN, particularly if you are staging first, but a version update might be painful. Autodeploy might make them want to go home and kick their dog if multiple remote servers had to reboot.
You could do local TFTP/PXE for booting hosts and go with a good old fashioned kickstart script for initial deployment, host profiles with answer files for compliance, a combination of a local web server per site hosting offline bundles and vMA esxcli commands for installing updates, and Update Manager for assessing updates compliance and for deploying smaller updates.
They really should removed the 1:1 restriction for Update Manager by now, it doesn't make sense to be this restrictive anymore.IT guy since 12/00
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands... -
QHalo Member Posts: 1,488DFS share for the VUM repository and patch via CLI script. The script would be the same for all sites since the namespace would be the same.