Now that the evolution of topologies and high availability with Log Insight is known, I would like to cover greenfield and brownfield deployments as well as security considerations. Read on to learn more!
Greenfield: Large and/or Production Single DC
Log Insight should be the aggregator of ALL environment logs and the CFAPI (e.g. Log Insight agent) should be used everywhere possible.
Greenfield: Large and/or Production Multiple DC
In the case of multiple datacenters, or potentially even multiple network segments, a Log Insight forwarder instance or cluster — depending on business requirements for availability — should be deployed to each datacenter and configured to forward traffic to a central LI cluster that only received forwarded traffic.
It is important to note that geo-clusters ARE NOT SUPPORTED! A forwarding instance/cluster is a dedicated Log Insight instance/cluster that is completely separate from the central, upstream LI instance/cluster. The below architecture IS NOT SUPPORTED!!!
Greenfield: Large and/or Production DR
If DR is required then the recommendation is to send all traffic to a Log Insight forwarder (instance or cluster) and have the forwarder send traffic to two separate LI instances/clusters in two different geographic locations.
If client-side DR is required and supported by the client then you could also configure the clients to send events to two different Log Insight forwarder instances/clusters (note this is overkill for most environments and the Log Insight agent only supports sending to a single destination today).
Brownfield
In a brownfield, the easiest place to begin is to configure the existing third-party syslog aggregators to forward events to Log Insight. Of course, the goal would be to remove the third-party syslog aggregator, but depending on the client configuration this may be a non-trivial task.
Greenfield: RBAC
If data isolation is required then Log Insight role-based access control should be used. There is no need to create dedicated Log Insight instances/clusters per access desired. In the below architecture, clients are sending traffic to a Log Insight forwarder cluster which in turn forwarders Log Insight to a central Log Insight cluster — you could tag forwarded information if desired.
Brownfield: RBAC
If an existing third-party syslog tool is being used and cannot easily be replaced then the recommendation is still to have Log Insight be the aggregator of ALL environment events, but then to configure Log Insight to forward the events required by the third-party syslog tool. For example, if an existing SIEM tool existed then the architecture would look like:
Security
When deploying any Log Insight components, be sure to read the Security Guide first. If you have, then you will know that it is strongly recommended that you put a firewall in front of your Log Insight deployments. Your business requirements will dictate whether just inbound firewall rules are needed or if outbound are needed as well. Below is a depiction of all security considerations that should be taken into account — again note the only strong recommendation is to put a firewall in front of Log Insight and restrict the inbound ports.
Summary
For greenfield environments the deployment options for Log Insight are easy, but keep in mind that geo-clusters are not supported. For brownfield, it is easy to start by configuring the existing third-party syslog aggregators though the long-term plan should be to replace the system aggregators. When it comes to security, a lot of considerations should be taken into account, but at the very least you should restrict the inbound ports to a Log Insight instance/cluster via a third-party firewall.
To wrap up this series, my next post will list the top four Log Insight reference architectures.
© 2015, Steve Flanders. All rights reserved.
