Cloud Plugin best practices

Usage and Config
1

According to this doc, it says that it is recommended to only have 1 cloud plugin installed per Cloud provider.
https://help.hcltechsw.com/bigfix/10.0/platform/Platform/Config/c_planning_cloudplugins.html

However, the capacity planning guide says that a single cloud plugin server can only support up to 10,000 endpoints. For our AWS deployment we have over 10,000. Does that mean I cannot use the cloud plugin to manage our AWS deployment?

2

Yeah, that’s still unclear to me why it’s really needed. We’re doing about 9,000 clients accross 3 plugins on one server. No one yet has suggested we make a change to that from multiple support people and a tech advisor.

Now it’s working “ok” at best. I have about 3+ open tickets currently.

  1. CPU usage at service start - Anywhere from 1hr to 10hrs (roughly) to check in & report back to the master to all plugins the first time CPU typically dies back to under 1% but other times it just stays at 25% (4 core) full time until I restart the service.
  2. The plugin page in WebUI will sometimes just go blank for hours / days at a time. Normally once everything checks in for a while, it just comes back online and works.
  3. AWS Cloud Trail failed login attempts if using SCP. This isn’t inherently an issue with just BES, other tools do this too… just something to be aware of and ensure your security teams / infrastructure teams are aware
  4. Have not fully researched this one… but, when upgrading from 10 to 10 patch 1, it uninstalled my vmware plugin fully in our Dev environment.
  5. It’s extremely memory hungry. The process typically rests at 2.5gb for us.
  6. Sometimes you just have to restart the service/server if the CPU won’t settle down.

So it works… jsut be mindful there may be issues ahead… and it’s always worked for us, just with various issues / learning.

3

As I say that… It’s at 3.6gb at rest today.
image

4

It’s running :slight_smile:

image
image701×592 49.3 KB

5

Sure, so you have 3 plugins installed on 1 server with a total of 9000 clients and that it is supported.

If you had 15,000 alone in Azure for example, that would be too many for 1 plugin server and splitting it up among 2 plugin servers is not recommended.

So is it just the immaturity (for lack of a better word) of the cloud plugin that causes these hurdles?

6

From my discussions with HCL, you are correct in just lack of maturity.
Version 10 is supposed to be the core foundation for the future, so various functionality is at a MVP level (so to speak). We are new to BigFix, and deploying 10 out of the gate into production. Outside of learning issues, we have had no road blocks and no huge issues. Most easily solved, solved in patch 1, or just waiting for it to mature.

I would for sure go for it with cloud plugin and can always start with 1 cloud plugin server and change if needed later… or dedicate 1 to AWS and 1 to everything else.

7

Yes, that’s the plan. Just not sure how it’s going to work when I deploy the AWS plugin to server1 and the Azure plugin to server2 and AWS will try and pull in 25,000 instances.

I also have an enhancement request submitted to have the multi-cloud plugins support more instances . Please vote if you agree.
https://bigfix-ideas.hcltechsw.com/ideas/BFMCLOUD-I-7

8

Just a curiosity on the usage of the cloud from people who actually use it :stuck_out_tongue: Do you have 25k fixed instances or do you have 25k instances on average that comes and goes?

9

Of our 25k+ in AWS, some are long lived, some are terminated and rebuilt daily.

10

So on those terminated and rebuilt you would have the BESAgent installed on the AMI? or you wouldn’t have the BESAgent at all?

11

Our AMIs have the BES Agent installed. However, not all of the 25k were built from our AMIs (they may use the marketplace AMI) or they were built from our AMIs before the AMI contained the BES Agent.