Network topology
Server Architecture Overview
PhixFlow is built on a single Java-based architecture i.e. it is not made up of several products with different architectures bolted together. There are two main elements in the server architecture:
PhixFlow Application Server - The PhixFlow application server is a Java-based application which runs within an Apache Tomcat container. PhixFlow supports installation on both Linux and Windows based servers.
Database Server - PhixFlow uses any major JDBC compliant database to store both configuration data and the results of analysis on data collected from other systems.
See System Requirements and Compatibility for information about supported versions of third party software that should be installed on the PhixFlow server, in particular, databases, Java and Tomcat.
Figure 1 shows the most typical deployment of PhixFlow in which the application server and database server run on separate machines, however, for small proof of concept installations a single server may be used to host both the application and database servers.
Figure 1 Dual Server High Level Architecture
Example network topology: reverse proxy
The diagram below shows Illustration of common network topology for PhixFlow deployments using a reverse proxy.
Benefits of using a reverse proxy
Using a reverse proxy has several benefits:
It can act as the point of SSL termination, i.e. it will serve the certificate for the service and decrypt the traffic that arrives from users via HTTPS. Many reverse proxies included useful helper functions for managing certificates.
It can further simplify certificate management if you have several installations of PhixFlow; they can be set up to be available at the same FQDN (using a single certificate), at different directories; e.g. phixflow.mycomany.com/production , phixflow.mycompany.com/test , phixflow.mycompany.com/dev.
They can be used to help manage the load on the system, providing an earlier point of failure for users rather than letting all requests on an overloaded system reach the back end servers.
They can be patched more aggressively than back end servers, for which stability is usually crucial. This is true for the reverse proxy and the server it sits on. This is important because this is the point which faces out to a wider network (your corporate network or the public internet), so is a potential point of attack for bad actors. There is no direct entry via HTTPS to the back end servers (administrative access must be allowed, but each infrastructure provides it own ways of doing this securely.)
Using a reverse proxy on a single server
You can install a reverse proxy on the same server as Tomcat; or indeed have a reverse proxy on a single server with Tomcat and the database. This is not recommended for production loads, but can be suitable for short term test instances. Even in this case, you get most of the benefits listed above.
Choice of reverse proxy
Any reverse proxy can be used providing that the Minimum System Requirements for PhixFlow are met. However, we recommend:
IIS on Windows
NGINX on linux. Example instructions for installation of NGINX, and installation of certificates provided by Let’s Encrpyt, is given here: Install NGINX
Illustration for a single instance of PhixFlow
A common set up using a reverse proxy is illustrated below, on Azure. This can be applied in a similar to any virtualised environment.
In brief, in this scheme, connections terminate SSL on a reverse proxy, these connections are passed on to application server within private network
Key components are:
Components | Description |
---|---|
Azure Network Security Group (NSG) - this can be any Layer 3/4 firewall | |
MySQL database - this can be any of the supported database | |
Server - linux or Windows | |
Azure VNet | This could be any private network. |
Reverse Proxy | Often NGINX on linux or IIS on Windows, but any reverse proxy could be used. In this example, the reverse proxy terminates the SSL and passes on unencrypted connections safely through a private network the application server. |
Illustration for multiple instances of PhixFlow
Using this scheme you can provide access to the instances of PhixFlow under a single FQDN, e.g. phixflow.mycomany.com/production, phixflow.mycompany.com/test, phixflow.mycompany.com/dev.
The example installation of NGINX explains how to do this: Install NGINX.