I have private cloud with 10000+ endpoints server to manage , we have high speed local disk available at ESX , should i take hardware server only for root or i can take VM to provide 10K / 20K endpoints servers
is it only disk is the limitation in VM or other things as well?
Disk I/O is the biggest consideration. We tried VM once, but reverted to physical. Unless your ESX admin can guarantee non-shared flash storage, you may want to think twice about VM.
We run a 13K environment. We’re successful with multiple RAID 10 arrays of enterprise grade SSDs in both our app and SQL servers.
Hi,
@JonL is definitely right about the disk requirements.
Ironically, the only environments I’ve ever setup physical BigFix Servers for were all < 100 Endpoints. I’ve setup and maintained dozens of large BigFix Environments on Virtual Environments.
It does require a certain amount of tuning and care if you don’t have screaming fast disks. If you have 10k RPM or 15k RPM disks, those are not fast disks.
There are lots of things you can do to reduce the Disk I/O requirements of your environment including reducing agent reporting interval, reducing command polling, limiting console operators, setting up fake root or top-level relays, setting up decrypting top level relays, etc.
The challenge is that you can easily make a 1000 endpoint environment run like crap on fast physical hardware and you can make a 25,000 endpoint environment run smooth on slower virtual hardware.
Hi @strawgate , i got your point , but i have seen personally few internment where root server on VM makes issue due to low latency of Disk I/O , do i need to have mentioned tuning for better performance and response time i do not opt physical hardware?
what is the meaning of setting up fake root / top relay?
So the with any performance situation we have a couple parts, what is our ability to provide Disk I/O and what is our consumption of that Disk I/O.
In other words we have capacity and we have utilization, those are our two variables. In any situation where you are dealing with performance issues you are going to make a decision to spend time resolving one of those variables. You can either increase capacity or reduce utilization – both have the same effect of bringing performance inline with your expectations.
One thing you can do to reduce load on a BigFix Root Server is to make sure that as few things as possible are talking directly to the server. Ideally you should have at most 2 things talking directly to a root server:
You should not have anything else talking to the root server.
Choosing a physical server has additional costs that a virtual server does not, including that it is non-trivial to upgrade the hardware, you must replace it every 3-5 years, and that a single hardware failure could bring down your root server. There are management and rack costs for that hardware as well.
Choosing a virtual server has potential issues if your disks are not fast enough or you are standing up the virtual server on over subscribed hardware.
If you put every server that any vendor ever said, “We run better on physical hardware”, on physical hardware, you would not be using virtualization and you’d have a datacenter full of pizza boxes doing one thing each.
If there is no additional expense to trying the virtual hardware first you can always stand it up on virtual hardware and migrate to physical hardware later if performance is an issue.
This is a really good point. You can always do a server migration to a different virtual or physical server, which if you are doing proper Disaster Recovery testing, then you would already be doing it.
You referenced a Console Server - does that imply there is a way to delegate the console content to flow through a different server than the root server?
I actually mean that you should avoid having BigFix operators use the BigFix console on the BigFix server itself. For the best experience I typically recommend having a co-located windows terminal server that operators can run the BigFix console on.
This is briefly mentioned in the guide:
https://help.hcltechsw.com/bigfix/9.2/platform/Platform/Adm/c_overview_of_the_tivoli_endpoin.html
BigFix consoles:
Join all these components together to provide a system-wide view of all the computers in your network, along with their vulnerabilities and suggested remedies. The BigFix console allows an authorized user to quickly and simply distribute fixes to each computer that needs them without impacting any other computers in the network. You can run the BigFix console on any Windows Vista 64-bit, Windows Server 2008 64-bit, Windows 7 64 bit, Windows Server 2008 R2 64-bit, Windows 8 64-bit, Windows 8.1 64-bit, Windows Server 2012 64-bit, Windows Server 2012 R2 64-bit computer that has network access to the BigFix server. Consoles for large deployments are often hosted from Terminal Servers or Citrix Servers.
Awesome. We are running into consoles lagging after upgrading our license and having a lot more content available. Maybe running on one of our VDI pools is the answer.
Thanks!
A few things to note:
default is it downloads a few gig of data to your local user profile folder, and depending on network and disk speeds it may affect your performance of the console.
Validate you have enough memory available for the console. Newer BES Console versions take less but ensure you have 1-3g of memory for it.
Remember that Console speed is not a direct measure of Bigfix backend performance, as the entire architecture is based on Asynchronous aka batch like communications and actions. Just because the Console doesn’t show an action started 2 mins ago doesn’t mean it didn’t actually finish in less than 30 seconds.
Personal experience running Bigfix console over a slow 20-40ms link (aka vpn) or low bandwidth connection is painful. Persistent VDI, App Presentation thru Citrix, Vmware, or other system to remote to on-prem with less latency is significantly better.
The below link outlines how to change the location of the cache.