DescriptionWhat information is required for our networking team
Installation and Administration
SolutionZoneFox staff are not experts in our clients infrastructure. This article details what each of the layers are and what they need to interact with, this information will help your networking team provide the best possible solution for you.
Presentation Layer
This will sit on a single Windows machine either on its own or as part of one of the Collector Layer nodes. This does not need to be load balanced but can have a DNS setup for it such as console.zonefox or gui.zonefox.
Note there are internal communications between this machine and the Collector Layer nodes on port 8004, these cannot be load balanced instead they are defined at setup based on either their hostnames of IP addresses.
Ingress - Gui, port 443 (https)
Egress - Communications, port 8004
Collector Layer
Windows based with an Ingestion and client management API. The Ingestion API takes in the endpoint data and sends this onto the processing layer as a Kafka Message, internally it also processes the events for policy breaches. The most important part in terms of load balancing is the client management API which authenticates and authorises the endpoints to allow them to send their data in, this is in the form of a session token which expires daily. This session token is bound to the Collector Server which created it. This is why the DNS requires a TTL at this end to ensure it doesn't need to re-login into the collectors every time it wants to send data in.
Note there are internal communications between these machines on port 8004, these cannot be load balanced instead they are defined at setup based on either their hostnames of IP addresses.
Ingress - Endpoints, port 8080, communications, port 8004
Egress - Processing layer, port 9092, database layer, port 9200
Processing Layer
Receives data in via a Kafka queue, Kafka for ZoneFox is not clustered so is local to the machine that is processing it. We then process these events, mutate them and send them onto the database. The inbound data is sent via TCP to port 9092 and is a binary protocol meaning it cannot have a simple http check applied such as a health check to it. If the VIP can handle these scenarios then it would be good to monitor for failures of this port but may be a little trickier. Internally we have mechanisms in place to tell if the Kafka we are pointing to is down or not receiving messages, if this occurs we report to the endpoints that the Kafka queue is dead and will switch them into offline mode for a period of 15 minutes.
Ingress - Kafka queue, port 9092
Egress - database layer, port 9200
Database Layer
This is built on Elasticsearch and has a simple http protocol which can be easily load balanced, although it is not a requirement to do so as internally the database client we use will sniff out the cluster and do some load balancing for us. However having a load balancing layer would be beneficial here as it gives us some redundancy if the node the processing/collectors are pointed to goes down at any time and it cannot determine where the cluster was/is. Note there are internal communications between the database layer nodes on port 9300, these cannot be load balanced instead they are defined at setup based on either their hostnames or IP addresses.
Ingress - Elasticsearch, port 9200
Egress - Elasticsearch, port 9200
