Hi all …
If you were setting up a BigFix deployment that monitored 80 servers, and you knew that there was little to no client growth expected over the next 2 years, would you deploy a BigFix relay?
I don’t think I would, but I want some of the experts to weigh in.
Thanks!
–Mark
I’ll let some customers say what they think, but the main reason for relays can depend on your network topology, and if UDP messages can reach everywhere or you have some segmentation. If its all one happy subnet then you might not need it as much
I wouldn’t deploy one. Would think the root server could handle that “load” without any issues.
I would recommend at least 1 top level relay for all deployments.
As long as your root server is spec’d right, then I don’t think you actually “need” a relay with less than 3000 clients except for other benefits that a relay can help provide like WAN optimization and bringing UDP to systems behind a NAT.
That said, you might consider having a single relay as a “fake root” for security reasons. This allows all clients to talk to the single relay as if it is the root server without needing knowledge of what relays exist in order to find one. This also means that you can isolate your root server so that the only things that can talk to it are the “fake root” relay and BigFix Consoles / Web Reports / Web UI / Similar. If you do not do this then that means any client that can talk directly to your Root Server can also access the BigFix REST API and be able to use the BigFix Console directly, which is not a good idea for security reasons. The other reason to do this is you SHOULD NOT have your BigFix root server itself accessible directly over the internet. You need at least one relay to serve this function, which can be your “fake root” relay.
The other reason to have at least one top level relay is that relays are fairly easy to swap out without disrupting BigFix as a whole. I recommend that your top level relay(s) and/or root have large caches to prevent the breaking of prefetches if a download is removed from the internet. It is very easy to expand the storage of the relay or make a new relay with greater storage, copy over the cache from the previous relay, then swap them out in DNS.
A single top level relay will also allow BigFix clients to continue to download files and send reports when the BigFix server is offline during an upgrade.
The top level relay(s) can be configured to batch reports together into bigger chunks before being passed on to the root server which can help speed up the root server’s ability to ingest reports if it does not have storage with high enough random IOPS or a fast enough NIC.
It just means having a top level relay with the DNS name of the Root Server as defined in the masthead file. The actual root server would be given a different DNS name. Everything downstream would think it is talking directly to the root server when in fact it is actually talking to the top level relay (fake root). The fake root / top level relay would have a manual relay assignment for the actual DNS name of the root server and/or an entry in it’s hosts file that points to the actual root server.
Because of this concept of fake root, and other considerations, it is not a bad idea for the hostname used in your BigFix masthead that points to your root server to be a CNAME DNS record that is something like bigfix.contoso.com while the actual DNS A record for the root server or fake root would be something like toplevelrelay.it.centraloffice.contoso.com or some other location. It could even be in Amazon EC2 or Microsoft Azure or anywhere else. It doesn’t matter, it just matters that the CNAME record that matches what is in the masthead points to the root or fake root and that you change the CNAME record if you move the root or fake root somewhere else with a different DNS A record.
@jgstew, this is great stuff. Thanks for taking the time to write this. In my case, it’s really a simple deployment - nothing Internet facing, all same subnet, etc. However, I’ll keep this configuration in mind. --Mark
Hi all … thank you all for your time and feedback on this. --Mark
I’d say the most important thing to do is have the FQDN in your masthead be a CNAME record in DNS that points to the actual root server FQDN, whatever that might be. This gives you the flexibility to change that CNAME record to point to somewhere else in the future, either the root migrated to another location, or a “fake root” relay, or whatever. It gives you the maximum flexibility for future use.
You might not want the FQDN in your masthead to be easy to guess, but that is mostly a weak security through obscurity.
Concur.
[post padding]
It’s already been said but I have a small deployment with a couple hundred systems and I deployed 2 relays using this fake root model for security.
2 relays for redundancy.
Keep client from directly talking to your root is good for performance also. Also putting the web reports server on a separate system is good for performance by removing that from the root server and a web accessible port open on the root server. The latest version 9.5.4.38 patches a vulnerability in OpenSSL that our qualys scanner picked up on the webreports service.
While this is true, and I agree it is good for performance, you can’t do this if you’re going to use ILMT (and probably BigFix Inventory, too). The VM Manager Tool somehow ties into Web Reports and there is an assumption made by the code that Web Reports and BigFix are on the same server. In my case, the 80-server deployment would be limited to ILMT.
–Mark
I don’t think this is correct. You can have multiple web reports servers, not just 1 and I think you can change the ports and stuff with settings. For very small deployments it shouldn’t matter but generally for larger deployments it makes sense to host basically everything external to the root server, though it might make sense to have a web reports server on the root server that is not accessible outside of the root server at all just for API usage and have an externally hosted web reports server for users.
Hi @jgstew … There was a thread about this in the ILMT form from last May. To the best of my knowledge, I don’t think this has changed. If you want to use centralized (default) VM management in ILMT, Web Reports has to be on the same server as BigFix. I have just asked for clarification.
–Mark
if so, you don’t have to use that web reports server for anything but the VM management and other APIs… you can have another web reports server for everything else.
I’m not sure how the VM management whatever is configured or how it talks to webreports. (SOAP? REST API?)
This is true.
Good question. I do not know this either.
–Mark
I would have at least one top level relay.
Why?
Because BESRootServer.exe is the single processing point of all HTTP traffic going to and from the BigFix Server:
Just to be safe why not split and reduce the network load so it looks like this:
Server
Top Level Relay:
At busy times in the deployment, you can be sure you will not receive HTTP 28 timeout errors in the console or API. It safeguards against a potential DOS of the Console/API connecting to the main server.
The top level relay will also compress client report files into single archives so the FillDB process on the server has less files to process (and so I am assuming less disk I/O).
It is also generally better from a network perspective to have fewer larger packets than sporadic smaller ones.
The requirement to have Web Reports on the same server as BigFix if you’re going to run the IBM License Metric Tool or BigFix Inventory has not changed.
Web Reports: A component of the BigFix platform that is required by License Metric Tool to configure VM managers. Web Reports can be installed during the installation of BigFix, and must reside on the same server.
–Mark
I read that as Inventory needs to be on the same server as WebReports, not that they both need to be colocated on the BigFix server itself.